Issue #14137 has been updated by Chris Price.
One thought, though... the output from a REST call currently looks something
like this:
{
"line": 1,
"file":
"/home/cprice/work/puppet/test/master/conf/modules/resource_type_foo/manifests/my_parameterized_class.pp",
"arguments": {
"param1": null,
"param2": "\"default2\""
},
"name": "resource_type_foo::my_parameterized_class",
"type": "hostclass"
},
{
"line": 1,
"file":
"/home/cprice/work/puppet/test/master/conf/modules/resource_type_foo/manifests/my_defined_type.pp",
"arguments": {
"param1": null,
"param2": "\"default2\""
},
"name": "resource_type_foo::my_defined_type",
"type": "definition"
},
If I change "type" on the query string to "kind", it seems like I should change
it to "kind" on the output as well. That's also an easy change, just wanted to
mention it to make sure no one has any objections.
----------------------------------------
Feature #14137: Usability improvements to resource_type REST API
https://projects.puppetlabs.com/issues/14137#change-61277
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.
