Issue #14137 has been updated by Chris Price.
I'm glad you commented, Randall. The word "type" is extremely overloaded here, and it bugs me... but I'm not sure what to do about it. As I understand it, the "resource_type" service is intended to return, basically, definitions of custom "types" that users have made available in their environment. So, "https://blah/resource_types/*"; basically means "give me back the definitions of all custom types". In practice there are currently three different categories that these definitions can fall into: "classes", "defined types", and "nodes". These aren't exactly "parent types" but that's about as close as I've come to inventing terminology to disambiguate the use of the word "type" here from the use of the phrase "resource type". To give a practical example: The puppet apache module includes a defined type called "apache::vhost". In the current version of this API, this is considered an instance of "resource_type", which has a property called "type" on it, whose value is (roughly) "defined type". There might also be a parameterized class defined by the module; it might be called "apache::foo", which would be another instance of "resource_type". It's "type" property would have the value "class". A query with "?type=class" would return "apache::foo" (and all other classes), but not "apache::vhost". A query with "?type=defined_type" would return "apache::vhost" and all other defined types, but not "apache::foo". To keep the scope of this problem manageable for the Telly timeframe, I don't think I can change the use of the phrase "resource_type" in the URL. I can, however, very easily change the name of the parameter that we use in the query string ("?type=blah"). I would welcome suggestions on that. ---------------------------------------- Feature #14137: Usability improvements to resource_type REST API https://projects.puppetlabs.com/issues/14137#change-61256 Author: Chris Price Status: Accepted Priority: High Assignee: Chris Price Category: service Target version: Telly Affected Puppet version: Keywords: Branch: In order to improve the ability for an external tool to support parameterized classes and other functionality, we need to make a few improvements to the REST API for the resource_type service. The main shortcomings with the current version are as follows: 1. The "search" mode does not support filtering by type; every query returns instances of all three types (classes, defined types, and nodes). 2. The field names on the output objects are confusing. They use terminology / names like "hostclass" which are, for practical purposes, internal / implementation-specific terminology. The output should use names that are more consistent with our documentation / DSL / external exposure of these constructs (e.g. "class" instead of "hostclass"). Proposed changes: ----------------- To address concern # 1 above, the proposal is to add support for a query parameter to allow filtering by type. So, e.g., you could issue a query like this: <pre> curl -k -H "Accept: pson" "https://localhost:8140/production/resource_types/*<b>?type=class</b>" </pre> The new bit is the part in bold: <b>?type=class</b>. This would also support the values "defined_type" and "node". The behavior would be to simply filter the result set to the type that is specified by this query parameter. To address concern # 2 above, we will modify the code that transforms the objects to PSON before serializing them. This will involve renaming fields/values that are not named clearly (e.g. "hostclass"=>"class" as mentioned above), and may also include eliminating some unnecessary fields from the output. I will add more comments to this ticket as I determine what changes seem appropriate. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
