I’m looking at the Reports screenshot in this post and there’s 2 places where I would indeed expect to see just those 3 states.
First (going from the top) we have Puppet reports with a small table under it. There I would expect only those 3 with counts of the reports. They now look like links and I would expect that if I click it the visible reports table is filtered or I’m redirected to another listing with only those reports.
Then there’s the table with the Status column. There I would expect the same. Only the summary would be based on the metrics.
I realize I was involved in this earlier, but being on PTO for 2 weeks has created the clarity to take a fresh look at this.
Thanks for the description of the background for this!
I think we should. It’s the single most important differentiator for reports, and a lot of puppet reports are going to be non-eventful, so I think it’s valuable. As a puppet op I interpret all 0’s as different than “successful changes with no errors”; it may be interesting that changes are happening when not expected, even if they’re happening successfully.
restarted should map to “applied” here I think, rather than “other”. Since restarts are the result of a successfully managed resource working as expected. skipped I would argue belong to “failed” (since skips in puppet are usually caused by a dependent resource failure, puppet refuses to manage anything beyond it in the dependency graph). out_of_sync - is this even reported on individual resources? We never used that, but we did noop only by exception and it was a bug if it was on too long. If it is there, it seems like it should be “pending”. total we used to sum up and use for public presentations, mostly. It’s useful in situations where you have generated resources (or recursive file management), but in my mind doesn’t belong on the “front page” of the report, maybe in details.
Yes, that is correct everything with a non zero value would be eventful. And perhaps it is not so important for everyone, but it should be as there is some error in your puppet code when there is always a change reported, you need multiple runs to finish without failure and so on. In many environments this is ignored which will then cover some important failure later on. I have seen this too many times.
This would be great for complete noop runs (like executing the agent with --noop for testing), for resources which have the noop attribute set. The later is seldom done, but have seen it in some environments where someone wanted to be informed by puppet, but apply the change manually. With noop if a change would be applied, it will be marked as pending.
You could also argue for pending, as it has not failed as it was never tried.
The three summary columns are: changed, unchanged, failed.
Let’s add a new table column on the report index page (thus also host detail - table pane) next to the summary field named “Major keywords”. This column can show some keywords (user configurable via settings) that can be interesting. Typical keywords I would expect there: PuppetNoop, PuppetCorrectiveChanged, PuppetSkipped or PuppetRestarted. For Ansible these would include: AnsibleUnreachable, AnsibleIgnored or AnsibleSkipped. EDIT: After chat with Maria we thought it would be more intuitive just to show Keywords column with nothing when there are no keywoard or number with number of keywords with some interactivity.
Here is my further feedback on the UX design of the host detail pages:
On each of the detail page (Ansible/Puppet) we whould show the three summary counters as well as tool-native counters (aka metrics). Ansible has: ok, changed, failures, unreachable, rescued, ingored, skipped. Puppet has: corrective_change, skipped, restarted, failed_to_restart, scheduled and out_of_sync.
Summarizing from the UX meeting today- I’m concerned that if a user doesn’t know what those 3 words mean intuitively (changed, unchanged, failed), the summary won’t be useful. The alternatives mentioned were (a) the user picks 3 important native metrics (from the Puppet list of corrective_change, skipped, restarted, failed_to_restart, scheduled and out_of_sync) and we show those; or (b) we keep the summary columns and add tooltips to show which native metrics they are composing. Now that I’ve written it out here, I feel like (b) is probably better.
The problem is, which one to pick? Can you define which one to pick for both Ansible and Puppet? See New config report summary columns for more details about the situation.
See, Puppet is 1:1 mapping, Ansible is a bit challenging that is 4:3 mapping when unreachable is actually treated like a failure which it is, but Ansible puts this into a separate bucket. This might look like we need 4th column, but we have been there - how to name this column? Other? Unreachable? How about Chef and Salt?
What I like about the current design is that we have three pretty much well defined counters: changed, unchanged and failed. And we present them in an intuitive way on the index page (icons), the name is shown only if you hover over it. It looks consistent. Of course, it is easy for us to show native labels, so instead of “Failured” for Ansible we can show “Failed or Unrechable”. The same we can show on the detail screen as well.
Keep the three summary columns
Let’s name them changed, unchanged, failed in the database and models
Let’s use icons on all pages
Let’s use hover mechanism to show native names
Let’s also show the original metrics on the detail page - ideally presented them in the most familiar way users would exit, e.g. for Ansible:
After a long discussion with community, we come up with this solution:
We are going to have summary statuses with values Failed/Changed/Unchanged, but also we will display Puppet metrics/Ansible metrics in an expandable card.
Thanks go to @lzap that has greatly driven the discussion. Note: mocks are just for the Puppet type and they contain just a dummy data
So here it is: Host detail puppet tab - expanded card (default)
I like the current proposal, the filtering links Ansible/Puppet on the Reports index page are little bit big to my taste, but I am okay.
The ring notification icon, I don’t know. Feels weird, but on the other hand I am not sure what to pick: PatternFly 4 • Icons
Some candidates for changed icon other than bell:
pficon-on-running - representing that actions were running
pf-icon-orders - representing a checklist - something was checked
pf-icon-rebalance - representing that desired configuration state was achieved (rebalanced)
pf-sync (fa-sync-alt) - ditto (synced)
Just a reminder: mouse hover will explain what changed/unchanged/failed mean to the users, I think combination of icons and overall status (Empty/Failed/Changed/Unchaged) is the best from both worlds and I like this.
Agree on icon, especially as in the mockups a yellow bell is used for changed and a black one for notice.
From the four mentioned I would opt for sync as it looks best for its own, but not sure how it look will next to two other round but filled icons.
I like the sync option more, I also think that yellow color is kinda okay. It pulls attention, maybe too much tho. I would be okay if the sync icon was black and white too. But I am okay with yellow to, we need to finish the design after all. Ten people, ten preferences.
While I have no strong opinion on the icon, just yet, other than I’m not quite sure on the current options. And maybe the community could look at: pf-icon-automation, pf-icon-in-progress, pf-icon-migration, pf-icon-pending, pf-icon-process-automation, … — none jump out the right answer(s). Most are hard to “see” at smaller sizes, which may rule them out of contention, if they need to pass a clarity / intent test at these smaller sizes.
Main Point: I would say, blue is a better colour for in-progress / running status IMHO.
Justification: As to most people, I think, yellow/orange would be viewed as warning colour, and red an error. So a colour for “we don’t need your full attention yet” might be useful. Before others point this out, one could argue reasonably that, something in this new colour for extended period of time, might deserve a yellow/orange colouring.
First of all: I quite like the new design! I think, it’s impossible to make it 100% perfect for every use case, but as far as I can tell, I would be happy to work with the shown design.
Regarding the “changed” color: I think it depends on the type. Puppet knows about corrective and intentional changes. Puppet Enterprise uses blue (intentional) and yellow (corrective). As we (Foreman) doesn’t differentiate between those types, I would also lean towards yellow as the more dominant color.