Jira (PUP-3642) Remove environment name from URL path

[Christopher Price (JIRA)]

Title: Message Title

Christopher Price created an issue   Puppet / PUP-3642 Remove environment name from URL path Issue Type: Task Assignee: Unassigned Created: 2014/11/07 11:27 AM Fix Versions: PUP 4.0.0 Priority: Normal Reporter: Christopher Price In order to make it possible to enumerate the list of URLs exposed by the master, we wish to remove the environment name from the URL path. Instead of being a part of the URL path itself, the environment name would become part of the payload of the HTTP requests. For GET requests, this would mean adding it to the query string; for POST requests, adding it to the form-encoded request body. I've done an initial spike to see how difficult this would be, and for the most part, it's pretty straightforward. Here's a hacky branch that I was playing with that mostly works: https://github.com/cprice404/puppet/compare/puppetlabs:3.7.3...scratch/3.7.3/url-rework Most of this change can be affected entirely in the network layer. The only part that seemed tricky was how to deal with PUT requests that get routed to a 'save' method of the indirectory. The thing that makes this challenging is that the indirector abstracts the serialization/deserialization of the HTTP request body into a model object, so it's not straightforward to try to add or read the environment value from the request data in the network layer of the code. This line is the main culprit: https://github.com/puppetlabs/puppet/blob/3a4b82e6f5b988d4e984b1f4954265f45cbe5660/lib/puppet/network/http/api/v1.rb#L61 In the case of a PUT request that is going to result in a 'save' call to the indirector, we don't have a way to access the environment name at this point in the code. We can't put it in the query string because the HTTP spec for PUT expects data to be in the body of the request, and we can't easily / generically put it into the body of the request because the body is created by the particular model class for whatever indirection is being used. In the case of a 'save', the body of the request hasn't been deserialized yet by the time we hit the line referenced above, so even if the body contains the environment data, we don't have a clean way to access it yet. A few lines later, we do some stuff related to the environment that is potentially very important: https://github.com/puppetlabs/puppet/blob/3a4b82e6f5b988d4e984b1f4954265f45cbe5660/lib/puppet/network/http/api/v1.rb#L66-L72 And it's not until a bit later that we actually deserialize the body: https://github.com/puppetlabs/puppet/blob/3a4b82e6f5b988d4e984b1f4954265f45cbe5660/lib/puppet/network/http/api/v1.rb#L158 After discussions with Nicholas Fagerlund and others, I'm relatively convinced that there are only two 'save' calls that we need to be interested in: report and file_bucket. I've already looked through the code for both of those, and they do not contain any logic that relates to the environment name that would have been pulled from the URL, so I think we are pretty safe in terms of there not being any real impact on those. Thus it just becomes a question of how to reorganize the code a bit to account for this difference between the types of HTTP requests. I can see a few possible paths to explore: 1. Simply don't check for the environment in the network layer if the request is a PUT/save request. The implementation of the individual indirector models could require/include the environment from the serialized object as necessary to satisfy the constraints of that particular indirection. 2. Move the logic that deserializes the body up to an earlier point in the request handling, and require that there be an 'environment' property on any model object that can be returned by this deserialization. Then, pass that object along through the rest of the call stack in the network layer so that we don't have to deserialize it again when we get to the 'save' call. Option 1 seems more coherent, but the implementation of it might involve a semi-gross special-case conditional in the 'uri2indirection' method, in order to avoid throwing the 'missing environment' exception for the PUT/save requests. Option 2 seems weird, because the environment may or may not be relevant at all to a given indirection when doing a 'save', so it seems like a pretty arbitrary requirement to say that the model objects must conform to that API. The network layer code, though, might end up with less special-casing. I'm leaning towards option 1 and will probably plan to spend a bit more time looking into whether or not there's some way to implement it without any kind of very gross special-case hack, but I want to solicit feedback from Andy Parker, Henrik Lindberg, and others before getting too far down any one path. Add Comment   This message was sent by Atlassian JIRA (v6.3.7#6337-sha1:2ed701e) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.