Just to put this into context, we are working on a new plugin named Foreman Host Reports which completely changes how config reports are stored. It is optimized for efficiency, Maria is designing the new pages according to the new data structures.
In short, reports are stored as JSON in text column, reach report has a date, proxy that reported it, host and most importantly four summary fields: applied, failed, pending, other. The idea behind this is to narrow down amount of states, Puppet is way too verbose and can overwhelm the user. Another reason is to keep the reports table as small as possible (minimum columns with indices). Reports can also have “flags” (called keywords), think about them as “tags”: pretty much any string that will be created during report upload.
Typical report will have keywords like “HasChange” indicating there was an eventful change, or “PuppetFailed://resource/name.pp” when a resource fails. The keywords are there so users can search for arbitrary things. After reading this thread tho, I think we should probably promote “changed” to a summary field.
The mapping is currently (looking for more feedback):
- changed → applied
- corrective_change → applied
- failed → failed
- failed_to_restart → failed
- scheduled → pending
- restarted → other
- skipped → other
- out_of_sync - ?
- total - ?
When a puppet report is eventful, the plan is to set HasChange keyword, but I struggled to figure out this. This needs to be done.
- applied → applied
- failed → failed
- skipped → other
- pending → pending
- changed → HasChange keyword
The open question is if we want to “translate” these four summary counters to something more meaningful on the detail page or not. On the index page, you can see these four summary counters has only icons, so when you open up Configuration Reports page, the data will be consistent even if you have multiple reports.
Then we have the Status column which is not stored in the database and it is just more elaborative overall status of the report. It is deduced ouf of the four summary counters:
- Passed - when applied > 0 and failed = 0
- Failed - when failed > 0
- No change - everything is 0
- Pending - when pending > 0
- Other - when other > 0
The question is if we want to have common overall status for all report types, or we want to map overall status per type. We need a feedback here - I would really appreciate if experienced Puppet and Ansible ops could help us to identify the best mapping and terminology here.
I like that the page is not just a table and the four panes are I think reasonable, showing the last status makes sense, but I think for better consistency, we whould keep the same name as in the Status column. In this case the last report was Failed so it should simply read “Failed”.
Please help us to find the best mapping and overall status of a report, see above.
No change is a bit fuzzy to me in the current design, how a puppet user finds out when there was no change? I think we had an eventful “virtual” flag in the old design and I think it makes a lot of search queries slower, if that is an important flag to have, let’s define it and store it in a separate summary column so we can quickly get those.
Looks like this is really important then, can you help me to figure out what reports are eventful in the current mapping design for Puppet? I think we need a 5th summary column named “changed” and when greater than zero, than a report is considered eventful. This would replace the “HasChange” keyword, I had no idea that eventfulness is that important.
If others share this opinion, we can simply have the format implementations to have a term mapping - on the puppet report, the four summary fields would be presented with a different name than on an ansible report. Help me to find those terms then and we can implement this.
As I said, the overall Status can also be mapped per report type if that makes sense. But we really need the feedback.
Resources, I think a mouse hover could explain that, to me it looks pretty clear.
Noop should create a “Noop” keyword and that can be presented easily. How you would like this to be presented both for Puppet and Ansible?
Thanks for the feedback so far, both from the UX perspective and from the technical perspective. I would really appreciate if you could help me to decide:
- Should we add 5th summary column “changed” so eventul queries would be faster?
- Can you find me mapping of all Puppet report states to our 4/5 summary columns? I am sure it is incorrect at this point.
- Can you review the same for Ansible? That one I am pretty confident we got right.
- Do you prefer tool-native names for the 4/5 summary columns?
- Do you prefer tool-native names for the overall status?
- Which overall statuses are meaningful to you for Puppet?
- Which overall statuses are meaningful to you for Ansible?
- We want to simplify the detail page - which graphs can we delete and which one to keep?
- Is there any feature you would like to see in the new reports?
- Which graphs/widgets on the dashboard page to keep and which to delete?