Foreman 3.0 new host detail page feedback

Hello,

this is the thread gathering user feedback for the new host detail page introduced as experimental functionality in Foreman 3.0.

We’d like to ask every user to provide a feedback for what’s missing on this new page for their day to day work. To set some expectations, it’s still considered experimental and we’d like to clean up several rough edges in 3.0.1, so it feels as really working replacement of the old page.

To enable this page, navigate to Administer → Settings → General and set “Show Experimental Labs” setting to Yes. Then navigate to the Hosts → All Hosts and in the action drop down for a particular host, click on the “New Details Page”.

There are some known issues with this page right now, such as the Edit button or the kebab menu next to it does not work. We’d also like to add a button to easily switch between old and a new page.
We plan to fix that in 3.0.1.

There are many tabs to be added, especially around Puppet, Katello, Ansible, OpenSCAP. The mockups for some are being worked on right now, some are already built and are being implemented.

4 Likes

IMHO these 2 things must be fixed in 3.0.1.

https://projects.theforeman.org/issues/33490
https://projects.theforeman.org/issues/33491

For convenience, a screenshot from my test setup:

My first impression is that there’s so much whitespace but in the places where it matters it’s cramped.

The Host Group next to the Mac Address (trivial bug: should be MAC Address since it’s an abbreviation) feels illogical and also gives you problems with the width:

image

Note that the IPv6 Address, Mac Address and Host Owner (isn’t my name a great testcase?) are split over 2 lines. The hostname at the top is also split over 2 lines when it’s a certain length (see first screenshot).

You can also see that in the audits table.

image

I’d like to hide audits by default because I can honestly say that I’ve never looked at them unless I needed to find out what changed when. The info in the current table is also not telling me anything. The current detail page has a link to the audits page and I’m very happy with that.

I also would like the host statuses to be expanded by default and not hidden behind a click. There is already a global summary at the top. Please give me all the info I need directly.

Looking at the details tab I think the Not Available use should be reconsidered. It is used in many places where it is optional. To me Not Available implies a problem I need to fix and makes me anxious. Perhaps just a dash to indicate it’s not there?

The Host Owner icon is also a person for both users and groups. Is this an oversight? In the current host page you can (indirectly) see the difference because a user is a link while a group isn’t. Probably not great UX, but it’s worth noting.

I’m also not a fan of the “Created … ago by … (updated … ago)”. To me it just takes up space and I don’t really care about the info that’s there. I’d suggest to remove it. In a Puppet environment (and probably also others) you’re pretty much guaranteed that updated is always < 30 minutes. Probably due to fact imports? However, you don’t find this in the audits so that is confusing. Removing that information is probably easier than solving the root cause.

Comparing to the old host page, I miss the Operating System icon that used to be there. The current badge style for the OS and architecture feel misplaced. In my environment I only have a single architecture (x86_64) and I think that’s true for a huge number of users. I wouldn’t show it so prominently. The current host detail page does it right IMHO: show the OS icon in the breadcrumb and leave the details to the details tab.

We’ve also lost some other info, such as Organization and Location. I always browse as an admin using Any Organization and Any Location so the top navigation doesn’t help me to determine that information. The boot time and Initial configuration are also Foreman features that are lost. And I miss the links to Facts and Reports.

The host status icon after the title also feels odd. I can’t exactly explain it, but I wonder if placing it before the title is better. Or just leave it out altogether since it’s already in the Host Status tab.

I know that work is ongoing to add support for Puppet in the Puppet plugin so I won’t comment on that.

2 Likes

Everyone who parses this thread for the feedback, please feel free to open RM issues and link it to the tracker https://projects.theforeman.org/issues/33499. For the time being I’ll be scanning this thread.

Opened as https://projects.theforeman.org/issues/33501

Opened as Bug #33503: Mac Address should have capital letters in the word MAC on the new host detail page - Foreman

Opened separately as Bug #33502: The host owner name should be expanded to the full width as it typically takes more than a one line - Foreman likely needs a different fix.

Not sure how you managed to break it that way, I have even longer host names but it works fine. Anyway I’ve opened this for investigation as Bug #33504: The new host detail page hostname should never be split to two lines - Foreman

Tracked as Bug #33505: The new host detail page audits card gets misaligned - Foreman

Before we start making things configurable per user or hiding some parts, I’d like to get more feedback.

The main idea for this card was, user can easily see whether there were some recent (and potentially unexpected) changes, e.g. if they see the host status is red. There’s still the link to all audits for the host. We may want to add modal to investigate audits in details from this page, without leaving the host detail. This is an RFE candidate.

I don’t think that’s a good idea, most of the host will be green (that’s what’s the sysadmin goal) and I don’t think that clutterring the overview with 15 not interesting statuses would be helpful. It’s a different situation in case the host is red. I’d definitely be happy to reconsider, but more feedback or thoughts from other users would help. Note that the card looks very different in case there’s at least one non-ok status. Perhas the counters form should be used all the time?

This feels as a nit, I’m not opening a ticket for this yet, @MariSvirik any comments on this? I think we had mockups with dashes but it didn’t look well. Perhaps using Unknown as the work would be better.

Likely an oversight, if the owner is a user group, it should have a different icon, tracked as

This is quite useful information in multiuser environment I believe. Also Foreman is used by people who don’t use Puppet. The created information basically tells you when the host was provisioned. Audits can be already cleaned up. It shouldn’t take much space, I’d only recommend moving this to a card or tab in case we’re out of space. Again, more feedback from others greatly appreciated.

Is this something that’s more relevant for Katello users? E.g. they need to know what repos to allow? It may distract the user a bit but it doesn’t take much space. Let’s see first what other content we’ll have there, this is easier to change later. @MariSvirik this comment is probably something to consider in future. Regarding the OS icon, I agree we should add it somewhere. While it’s not overly useful, it’s a cool eye candy :slight_smile: Note that one does not replace each other as this chip gives you info about the OS version too. Thoughts on this Maria?

This was discussed in a larger group, @tbrisker please keep me honest here but I think we didn’t want to repeat the values from the taxonomy switcher on top of the page. I see what you’re saying about the “Any Context” and I don’t want to derail the conversation here so just one comment on this, I belive Any Context should be removed and users should be always asked to pick one organization/location to work with. Let’s start another taxonomy thread if you want to continue this conversation.

Yeah, I’ve added this to the work roadmap and will work with @MariSvirik on the mockups.

@MariSvirik any thoughts on this? Just to be clear, we talk about the title of the host status card, which is not visible on the screenshot here. But it can be found in the original mockup https://community.theforeman.org/uploads/default/original/2X/1/1456fe1f035ad883151f0c38fe480e492dccdd40.png

All in all, thanks for the first feedback, my hope is we’ll have more comments on the topics above but also new writeups like this!

Right now I think the table is rather meaningless. What you see is 3 columns. The first column is the action. In my database I see 2 values: create for the very first entry and all the other ones are update. Technically you can see delete as well I guess, but then you’d have no host detail page. So I’d argue to drop the column.

The second column (date) makes sense as well as the user who made the change, but right now it’s an unintuitive way to actually view them. If you do keep this block, make the date clickable to view the full audit without having to go to all audits and finding the entry. This would be similar to how the host statuses expand.

I also noticed it shows something different if all statuses are green and I guess that could be OK. That wasn’t what I was talking about so let’s only consider the case something is not OK. I really want to see what. To me that’s one of the most important parts of Foreman.

Taking Unavailable | Definition of Unavailable by Merriam-Webster I think that this usage is incorrect but I’d be happy if a native speaker could weigh in.

Not Available suggests to me that there was an internal server error (at runtime) or something and makes me want to investigate why. Unknown suggests to me some import process failed.

It is perfectly valid for a host to not have a hostgroup (or IPv4 or IPv6 for that matter). The valid text would be No hostgroup but that’s quite long so you could go with None.

I don’t think that clutterring the overview with 15 not interesting statuses would be helpful. It’s a different situation in case the host is red. I’d definitely be happy to reconsider, but more feedback or thoughts from other users would help.

One option for handling this problem would be to have a kind of synopsis text, such as “Unknown subscription status. 2 traces need attention” which is generated from all the non-green statuses and available at a glance without clicking. This would give you more info than the icons alone.

3 Likes

For bootdisk, we need to have an option to extend buttons or/and hamburger menu. From the previous experience I believe that it should be the user who decides whats the most important for them to have available as handy buttons, not plugin authors.

So ideally if we would only make hamburger menu extensible and later on we could add some option for users to mark some actions to be also available via buttons.

I agree, the first thing that strikes my eyes is that the hostname is being wrapped. In your example, that is not even a long hostname, but our users often have prod-hostnames.which.are.really.long.like-332.really.long.com.

For me, obviously, what’s missing is provisioning. I really hope we will put that into a separate tab. For now, my only feedback would be that we show Primary NIC on the Details card and we could show the provisioning NIC on its own tab. There will not be much information on a separate tab, but I think we can start expanding this later on. Things that could go there in the first phase:

  • Provisioning-related properties
  • Templates and previews
  • Remote VNC
  • More fields pulled from related things like Operating System, Domain and Subnet

Generally, I would love to be able to move these “widgets” around like on our dashboard pane. I guess that is planned for later, but that will be really key feature to get rid of info you don’t want to see and putting important things to the front.

You would see more updates, which is the main value. Sure if you never modify your host you’ll only see only the create. I assume many users edit their hosts though, so they would see the last three updates.

that’s the modal I’m talking about, I’ll open the RFE unless someone comes with a different idea when we close this thread, not sure if this could be done in 3.1 release

I like that, we can present only the red and yellow sub-statuses in that case.

I think there’s a slot already in the kebab menu, @amirfefer will be happy to assist with this in the thread Host Details Page Redesign - Extension points once he’s back.

A bug already tracked as Bug #33504: The new host detail page hostname should never be split to two lines - Foreman

Hi,
I don’t know if I can leave this question here, but related to the current and future Host Detail page, after completing the upgrade to version F3.0, I no longer see the Lifecycle Environment and Content View information when I edit a host. Registering a new host show Content Source not defined either.
Is this a bug? The future page won’t show it either?

Thank you very much.

That’s a separate page and that sounds like a bug. Please open a new thread for that so it gets the proper visibility.

Keep in mind that Puppet features have been extracted into a separate plugin. Have you seen upgrade notes?

Sorry, but I don’t understand the relationship with the separate puppet plugin. It seems to me, as ekohl said, that this is a bug, because when I manually define this data (before they were completed automatically), they reappear empty when I return to this page. I’m going to open a new trhead. Thanks.

During the ForemanCon demo two things jumped out to me.

The first is the build mode. Today we display whether a host is in build mode by having a button (that’s always visible) with either the Build or Cancel build label. In the new detail page the button is hidden in the drop down mode so it’s less visible what state the host is in.

The other is the power status. I only saw On and Off actions but there are really more a few more:
https://github.com/theforeman/foreman/blob/e98fc0116a9a5bb80a2f1a15139f813943827240/app/services/power_manager.rb#L1-L4

I’m not sure what the exact logic should be, but is there anything tracking this?

I think we should be adding a provisioning tab or at least a section in details tab, where this would be visualized better. But for now, the kebab menu is probably the best place.

the ones you linked are only for the BMC (like IPMI) if I’m not mistaken. Some of them are even duplicates. I think we simplified the list to the following options

  • power off,
  • power on,
  • reboot (soft, ACPI signal to OS),
  • reset (warm boot),

However what you’ve seen on the demo was a regular VM, in this case AWS machine, which only supports on and off I think. In the old page, we had BMC and VM power control as a separate buttons, now it’s the single component that abstracts it.

we’re still tracking stories around the boot device selection through BMC, but we need the provisioning area first to be implemented.

Is that a hard or soft power off? Or soft with a timeout after which it’s a hard power off?

Is that a warm boot? Isn’t hard reset a better description? It would match the soft you used earlier.

I think you answered my question: that VM only had two implementations. Has a demo been shown with all possible actions? I’d expect libvirt to implement all of them.

For me it’s hard to test now since I don’t have a development setup (Fedora 34 has Ruby 3 and I haven’t spent time to set up an older Ruby). And the current nightly repos are broken due to branching which means I can’t install foreman-libvirt.

While testing on the nightly packages I have installed I do see the IPv4 and IPv6 spacing still isn’t correct if a window isn’t full width:
image
See https://projects.theforeman.org/issues/33948 for the full description.

This is the existing mapping in Foreman for BMC commands

                         :start    => 'on',
                         :stop     => 'off',
                         :poweroff => 'off',
                         :reboot   => 'soft',
                         :reset    => 'cycle',

the off command is implemented in various adapters on smart proxy, I can only speak about impitool , but you can easily find the definition for others. ipmitool describes it as

Power down chassis into soft off (S4/S5 state).
WARNING: This command does not initiate a clean shutdown of the operating system prior to powering down the system.

IMHO that’s not soft as you meant it, since it really means power off but in a way the machine still has some power so you can power it on e.g. with touching the keyboard. It’s not the ACPI command to initiate the power off through OS.

reset means cycle per the mapping above, cycle means the following:

Provides a power off interval of at least 1 second. No action should occur if chassis power is in S4/S5
state, but it is recommended to check power state first and only issue a power cycle command if the 
system power is on or in lower sleep state than S4/S5.` which basically does `off` waits a second and `on`

That’s probably useful when you want to make sure the disks stops rotating or RAM fully forgets. Anyway this is the mapping that wasn’t changed as part of this effort. However only unique statuses we kept to make it simpler.

For VMs we only expose on and off on the old host show page and on the compute resource page. The other operations are only accessible from the bulk action menu, there you can e.g. cycle the VM. We may consider adding this to the new host page too.

It looks like as an admin on the new page view I do not have the ability to edit ansible roles with the new host detail page, but I do with the old one. My admin role only checks the “admin” box, it does not grant each of the roles individually.

1 Like

There was a bigger chagne in Foreman 3.1 (and respective foreman_ansible version), however it still sufferfs from the same silly mistake. For the page without any role assigned, we don’t display the button to assign some roles. This is how it looks when at least some roles are assigned.

And this with no roles assigned

As a workaround, please either navigate to the host edit form - ansible roles tab or use CLI to assign at least one role.

cc @ezr-ondrej could your team add an edit roles button to the empty page?

2 Likes

Thanks for debugging Marek, I’ve opened an RM ticket and will get it on our teams backlog :slight_smile:

2 Likes

A fix was pushed to foreman_ansible:
assign_roles

4 Likes