Initial scoping / investigation for rewriting Pup 3.x URL requests to Pup 4.x

PE-8404 calls for some work to be done to allow Puppet 3.x agents to be able to send requests to a master containing Puppet 4.x and have the requests automatically converted to the new request APIs that Puppet 4.x now supports. This ticket is intended to capture any early scoping / investigation activities that would need to be done to support this functionality.

–

Potential Issues

• file_metadata response changed in PUP-3355 to remove PSON wrapper. Change is expected to be backwards-compatible.
• node response changed in PUP-3355 to remove PSON wrapper. Change is expected to be backwards-compatible.
• catalog response changed in PUP-3355 to remove PSON wrapper. Change is expected to be backwards-compatible.
• file_metadata query parameter links value changed in PUP-3935 for pluginfacts and plugins only. Might need to translate this.

Implementation Details

UPDATE: We had an engineering meeting on 3/30/15 to discuss this a bit further. Some notes from that meeting:

1) The only Puppet 4 master that will be required to support Puppet 3.x agent request mapping is a Puppet Server 2.x master, not a WEBrick or Rack master. This will allow for us to create a Puppet Server-only solution.

2) The "legacy" and "v2.0" master/CA Compojure routes had been removed for Puppet Server 2.0. These could be basically restored for Puppet Server 2.1, with some middleware function(s) which can transform the URL and request parameters in the Ring request map from the "legacy" / "v2.0" format to corresponding "v3" master / "v1" CA formats, as appropriate. Post-transformation, the request handlers could just call into the same functions that the "v3" master / "v1" CA handlers have been calling into.

Old routes:

https://github.com/puppetlabs/puppet-server/blob/puppet-server-1.0.8/src/clj/puppetlabs/services/ca/certificate_authority_core.clj#L239-L275

https://github.com/puppetlabs/puppet-server/blob/puppet-server-1.0.8/src/clj/puppetlabs/services/master/master_core.clj#L10-L78

3) It would be best for the code involved in performing the "legacy/v2.0" -> "v3" master / "v1" CA transformation to be isolated such that it would would be very straightforward to purge it later on. chris suggested we might be able to do this by consolidating the new code into a service which registers its own independent ring handler with the webserver. That way, removing the remapping logic in a later release would hopefully be as simple as just deleting the service namespaces. We could consolidate the Puppet 3.x compatible CA and master routes into a single service rather than spreading them across 2 services.

4) Remove the "not found" fallback route for the master and CA so that the Puppet 3.x compatible route ring handlers will be evaluated when needed:

https://github.com/puppetlabs/puppet-server/blob/0ca3d679dbdd4749f884729112f2f99aa6d50528/src/clj/puppetlabs/services/master/master_service.clj#L43

Also, take care that no new "not-found" route is added to any of the legacy routes that are being restored so that we don't adversely affect the ability for the new Puppet 4.x routes to be handled properly.

5) The solution should restore legacy compatibility not only for the URLs but also for binary file transfer. This would need to account for the work done in PUP-3812. For legacy "file*" requests, this may include:

• Map the Content-Type "text/plain" header to "application/octet-stream".

• Map the Accept "raw" header to "binary".

6) Assuming the URL remapping would be occurring at the Compojure route layer, a "legacy" URL would have been transformed into a Puppet 4-compatible URL by the time the incoming request could be evaluated against "auth.conf" rules. There's probably not any unique development work to be done around this aspect, but we should work with the docs team to ensure that this behavior is appropriately documented for users.
__________
Risk Assessment : N/A Initial Scoping ticket; testable code changes expected in other tickets