Puppet tab in Host details page - Proposal

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.

My vote to replace “Passed” is “Changed”.

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. :frowning:

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.

Did we manage the same puppet environments? Because it feels like we managed the same puppet environments. :slight_smile:

Yeah, I could definitely see that line of reasoning.

2 Likes

Thanks guys for reviews, I think the mapping deserves more attention so I am creating a new thread with the mapping, please review and discuss there.

I will let Maria to continue on her UX work here, we might end up renaming Summary and Status fields so please consider these WIP. Thanks!

2 Likes

Thank you all who participated on mapping refinement in New config report summary columns

Here is the result:

  • We are dropping the “other” summary column.
  • 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.
1 Like

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.

1 Like

3 things we could consider adding to @jeremylenz 's direct mapping idea:

  • Why not add a horizontal overflow scroll and just show a compact view of all items
  • If this is meant to be a dashboard you could enable a slow auto-scroll back and forth (seen this done).
  • Don’t show items with a “0” value.
1 Like

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.

My takeaway:

  • 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:
ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1   

With these two essentials I’m +1 to this. :+1:

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 :wink:

So here it is:
Host detail puppet tab - expanded card (default)

Host detail puppet tab - closed cards

How is it going to look in general Reports page (not in the host details page)?

Reports - index page

Report detail page

Any comments/ concerns?

2 Likes

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.

Thanks, it looks great now.

2 Likes

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.

3 Likes

@lzap @Dirk
Good catch, I’ve overlooked the icons on the detail page (there are months between those two designs) :sweat_smile:.

Here is a quick overview of the icons picked by Lukas and put in the context:

pficon-on-running

pf-sync (fa-sync-alt)

2 Likes

Still not sure which one I would prefer as the other two look more solid, leaning to the first one now, but would be fine with both.

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. :slight_smile:

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.

Just my 2 cents worth.

1 Like

This is why I prefer yellow here, changes in configuration management are something to be reviewed if not expected in my opinion.

2 Likes

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.

4 Likes

First of all, I want to thank you all again for this great discussion and your involvement.

I discussed the icon issue with the design team and we came up with the final decision to use the fa-sync-alt icon as its meaning is well established (as change) also outside the PF4.

Here it is:

I am aware that decisions like these are never going to be liked by everyone, but I hope it will nevertheless improve your experience just a bit.
Thank you

7 Likes