New config report summary columns

[ekohl]

In this post I already linked to the relevant reference documentation.

Puppet tab in Host details page - Proposal

Initially I wrote a long reply, but there is: Puppet report format version 12 Puppet report format version 11 Puppet report format version 9/10 Also, there’s a schema From that documentation, I wonder why we don’t use the status field at the top level. That’s an enum failed, changed, unchanged. These are the 3 states I would expect to see in the UI. The fact we do that today in our report processor is probably a historical reason to be compatible with ancient Puppet versions that didn’t hav…

@lzap

Puppet

What you are mentioning are all the individual metrics, but I think you’re missing some of the higher level this that make it much easier to parse.

First of all, at the top level there’s a field status which is an enum (failed, changed, or unchanged).

I really think that’s really useful since you don’t need to parse anything. The query becomes very quick. You can essentially use if (status != 'unchanged') { set_keyword('HasChange') }.

Then for the table, at first I thought you were referring to Puppet::Resource::Status in the report. However, later I looked at some more details and now I wonder if you are actually looking at this:

puppetlabs/puppet/blob/c4e72a38fad7d768a38a6f80d9a4c435a5ee9b8b/api/schemas/report.json#L304-L317

For that it’s odd that the reference documentation states:

Includes the metrics failed, out_of_sync, changed, and total. Each value in the resources category is an integer.

So please clarify what you are parsing.

I also think corrective_change is already captured in changed. Some background: a corrective_change says is that the change happened while the catalog didn’t change while a non-corrective change is when the catalog changes. The catalog changes (for example) when a classes is added/removed or some variable changes. In other words: the admin changed the expectations on the system.

So a corrective_change means that is something on the system wasn’t in line with the intended profile. However, a change is already a change. This would be good to test. I’ll see about writing up some tests.

If you do want to introduce a new feature, this could be highlighted. However, you also have it at the report level (so no need to get it out of the metrics). So you can set a keyword CorrectiveChange on the report itself so you can easily search for it. I think the log lines themselves already contain (corrective change) so there’s no need to do anything on the individual events.