[SERVER-264] remove usage of liberator Created: 2014/12/16  Updated: 2016/12/09  Resolved: 2016/12/09

Status: Closed
Project: Puppet Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: Kevin Corcoran Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: low-hanging-fruit, server
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to SERVER-149 Update URLs for Puppet4 compatibility Closed
QA Contact: Erik Dasher

Comment by Kevin Corcoran [ 2014/12/16 ]

I started hacking on this in the interest of getting a better idea of exactly what it's going to take. Here's my WIP: https://github.com/KevinCorcoran/puppet-server/commit/b9267b66c8b6e7a1a6e327ebb3aa92e78c6f1a94

And here are my other thoughts/notes:

  • We have 4 total endpoints/defresources : /cert_status, /cert_statuses, and the 2 admin endpoints
  • As seen in the commit above, I started using ring-json which provides middleware for auto-rendering maps, etc. to JSON strings ... I was surprised to learn that we are not already using this for our existing endpoints .... but I guess that none of the ones implemented w/o liberator return JSON, perhaps.
  • Error-handling is going to be the majority of the work. liberator has a specific API for this based on it’s DSL/decision tree … in the early endpoints we implemented in the CA, we throw exceptions from “internal/implementation” namespaces up to the namespace where the ring handler lives, catch the exceptions there, and turn them into ring responses. This code could probably be DRYed-up and perhaps some middleware extracted from it. This would probably be worth doing before un-liberating the /cert_status(es) endpoints.
  • The defresource implementation for /certificate_status is, by far, the most complicated - the two endpoints in the admin API are much simpler and also nearly identical, so that ring handler should be much easier to port than the CA's.
Generated at Mon Dec 09 14:11:11 PST 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.