Feature #12260
All puppet module commands should support json and yaml output
| Status: | Accepted | Start date: | 01/27/2012 | |
|---|---|---|---|---|
| Priority: | Low | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | module tool | |||
| Target version: | - | |||
| Affected Puppet version: | Branch: | |||
| Keywords: | geordi v2 | |||
Description
This shouldn’t be too difficult, but if it is, this can be broken down into smaller tickets per command.
Related issues
History
#1
Updated by Daniel Pittman over 1 year ago
Matt Robinson wrote:
This shouldn’t be too difficult, but if it is, this can be broken down into smaller tickets per command.
They should get this entirely for free, shouldn’t they, as part of the Faces API?
Oh, wait – I know why you have this problem. Your return data structure includes a whole bundle of console rendering specific support data, not just what the user requested, and so the output format – which is API – is much harder to manage.
Since you need to document the Ruby API anyhow, and that data format will be exposed to integrators, you might as well just document that around the JSON and YAML output too. It isn’t any uglier than expecting people integrating at the Ruby level to deal with the strange data format.
#2
Updated by Matt Robinson over 1 year ago
It’s not necessarily because there’s logic in the rendering so much as it is that the data returned includes Puppet::Module instances that don’t have a good to_json or to_yaml methods.
#3
Updated by Daniel Pittman over 1 year ago
Matt Robinson wrote:
It’s not necessarily because there’s logic in the rendering so much as it is that the data returned includes Puppet::Module instances that don’t have a good to_json or to_yaml methods.
Ah! Awesome. It would be much better to fix that problem at the Puppet::Module level, then, by giving them an appropriate format.
Given that the effort is going to be close to identical – you have to define the JSON/YAML format anyhow, which is the hard part – it seems like that should be about the same effort, but have a much greater payoff since we now have the ability to reuse that change elsewhere.
Which is probably what you planned all along, just not explicitly stated. :)
#4
Updated by Pieter van de Bruggen over 1 year ago
- Keywords changed from geordi to geordi v2
#5
Updated by Andrew Parker 6 months ago
- Target version deleted (
2.7.x)
#6
Updated by Michael Hrivnak 4 months ago
Pulp (http://www.pulpproject.org) invokes “puppet module” commands on remote machines and depends on the JSON output to report errors to users. It mostly works well, but there are certain cases (like installing a module that doesn’t exist) where we don’t display the error message, because there’s no JSON.
Our code makes a best effort to find and display each error message, so as JSON support improves in the “puppet module” commands, Pulp will automatically take advantage of it.
#7
Updated by Dominic Cleal 4 months ago
- Category set to module tool
re the errors issue in comment 6, I’ve filed this as #19409.