The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
The 'resource' handler needs to be refactored to use the Indirector and REST
|Assignee:||Sonny Cook||% Done:|
|Affected Puppet version:||0.24.7||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.
Currently, there’s an xmlrpc Resource handler that can provide information on resources and modify them.
This class needs to be refactored entirely to use the Indirector instead of being tied to XMLRPC. Most likely, the bits that talk to the RAL need to moved to a terminus type, and then we need a new Resource class that provides a simple model for resources. Hopefully, this class can be a model for how to integrate all of the different Resource models we have.
Once the class exists, it needs to be able to use REST for communication. Backward compatibility isn’t important here, because we’ll just keep the xmlrpc handler around. I think the only code that uses this class is the ‘ralsh’ executable.
#2 Updated by Sonny Cook over 4 years ago
It seems that the term ‘resource’ is used to refer to different things at the same time here. That coupled with my newness will likely lead me to be frequently confused. If I understand correctly, following are the potential uses we might encounter in this discussion.
- Rest resource – something accessed from a rest interface. Largely irrelevant excepting apart from the fact that we are using Rest.
- Manifest Catalog Resource – maps to Puppet::Resource and represents the generic interface to a logical catalog resource
- RAL Catalog Resouce – maps to Puppet::Type and implements (what appears to be) a lot of non-reversable ‘instantiation’ logic
Currently the xmlrpc hanlder addresses instances of Puppet::Type and marshalls them using (apparently deprecated) TransObject and TransBucket.
Objects of type Puppet::Resource already know how to marshall/unmarshall themselves for transmitting the catalog around via Rest, so if that is what we are looking at doing, it should be fairly simple. From talking to Ethan, however, it seems that the objects of type Puppet::Resource only form a subset of the eventual set the catalog will have for Puppet::Type. This seems like it would be insufficient, then.
It seems like you want to expose Puppet::Type to the Rest resource interface in order to get resources in and out of the RAL catalog. Is this it, or am I misunderstanding?
#3 Updated by Luke Kanies over 4 years ago
- Assignee changed from Luke Kanies to Sonny Cook
I agree it’s a bit complicated. We’re working on unifying the resource types, but for now, the Puppet::Type class has all of the behaviour, but they’re not modeled well for easy serialization. Thus, we always want to pass Puppet::Resource instances around, but will usually convert them to Puppet::Type instances in the end.
You should consider this interface to be an API for the RAL, which means it interfaces with Puppet::Type, but it speaks Puppet::Resource.
So, for instance, if someone is doing Puppet::Resource.find, you’ll need to come up with a URL key that will identify the resource (e.g., Puppet::Resource.find(“/file/etc/passwd”), or Puppet::Resource.find(“/user/foo”)), and then create a ‘ral’ terminus type.
This terminus type will know how to query the state of resources (basically, when find or search is called, it will create appropriate Puppet::Type instances, query their state, and convert the results into Puppet::Resource instances) and modify them (by turning Puppet::Resource instances into Puppet::Type instances, sticking them in a catalog, and applying it).
You can also look at ralsh for more examples, including modern usage (which the current resource interface is not).
Is that sufficient?
#4 Updated by Sonny Cook over 4 years ago
So, if I understand you correctly, externally, the object we want interfacing with the world is Puppet::Resource (hopefully I’m just restating what you said).
Internally, the thing we need to look at are instances of Puppet::Type since those describes the RAL resources that we are interested in. We need to locate the correct one(s) based on the URLs passed in, operate on them if appropriate, and then convert to Puppet::Resource to complete the request.
The ‘ral’ terminus will need to know how to handle all of this.
As I understand it, Puppet::Resource –> Puppet::Type conversion is currently a one way street, so the significant work here will probably be implementing the Puppet::Type –> Puppet::Resource conversion.
Does that sound about right?