RFC: New All Hosts page, wizard for package management

Hi everyone,
first, thanks to everyone who is contributing moving the All Hosts page to React - especially @jeremylenz - it is a great effort!

We would like to contribute and had a look at the new wizard for package management. The wizard allows to install, update and delete packages from hosts:

This wizard can be be used for one or multiple hosts. This is very convenient for one host or hosts with similar content. Now what if I have different OSes or different content for the hosts? At the moment, there is no limit to the host selection or what I can do to hosts that have different content.

While trying to integrate Debian packages, we were wondering where this is heading and what is a good way to provide the best user experience for those bulk actions.

Some initial thoughts are

  1. have all available packages of all hosts in a list (adds up to a lot of packages that cannot be installed across different hosts)
  2. extend the wizard have at least an rpm/deb filter (a bit better)
  3. extend the wizard to have a content view filter (at least, the package selection could be installed on all hosts with that have that particular content view)
  4. …

We very much appreciate all thoughts. Maybe, there is even already a design that we have missed?

Just for the sake of completeness: Here is the starting point of the original discussion that I have now moved to this discourse: Fixes #37347 - Add Packages wizard to All Hosts page by jeremylenz ¡ Pull Request #10962 ¡ Katello/katello ¡ GitHub

2 Likes

I think the problem is not only different operating system families, it is already different operating systems. In fact it may already be different systems as they may be the same operating system but use a different content view version and some may be upgrade and some not. So solving it can get quite complicated, but I think we can find a usable solution.

Action “Upgrade all packages” is fine, this is simple and works for all. It just gets complicated if we want to show a user all details. I am not sure if this is needed, but I remember this is a question asked by users quite often “How do I see what was updated from which to which version?”.

Actions “Upgrade packages” and “Install packages” can be solved in a similar way. We could show a list of combos of operating system and content view version. All providing a package list with installable versions for selection, by default collapsed if it is more than one to not overwhelm. A search filter could help with finding the package needed. If in a combo nothing is selected we drop it from the job before executing, otherwise we have to split it into sub tasks for every combo.

For “Remove packages” the same idea could work, but the list would be all installed packages which we should group by operating system. A search filter affecting all operating systems should be also helpful here, so you could search for a package name or a specific version which needs to be removed and see if multiple operating systems are affected. Then the job has to be split in sub tasks for execution based on the package(s) or even on the hosts, not sure what would result in less sub tasks.

Showing in detail what is affected per hosts in the “Review hosts” step can be a challenge, too.

Also if not a common task, would a “Downgrade packages” also make sense? Of course with some warning banner as it is a task you should not do without fully understanding it. But could be useful and we would not leave a user without assistance for this case.

So this only my idea from a user perspective, as I am not much of a developer, I have no idea if this could be implemented in this way to perform, especially on a large scale. But I hope it is still a helpful suggestion and helps with further discussion!

1 Like

By operating system, do you mean a specific version? Because packages that exist on EL 8 may not exist on EL 9 and vice versa. I think you’re right that having the same content view(s) is the only guarantee that installation works.

Though I wonder if install and remove are that much in demand. I’ve always seen configuration management as the correct place to do so. How often is just installing a package sufficient? Usually you also need some configuration. Also, if you install new hosts with the same profile you don’t want to manually install packages again.

Yes, I mean the exact version, I would also include the minor version as EUS on RHEL, SP on SLES and probably also dot release on Ubuntu already make a difference. Thanks for asking as it was clear to me, but I did not write it down so it is clear for all.

I would also recommend configuration management for package installation. But I see still to often manually oder semi-manually managed systems.
The use case of temporary installed debug utils like tcpdump which should be removed afterwards, but probably are not, would be something I see often. With the UI and Jobs keeping the information now it would be at least tracked when it was installed and someone responsible for Security could easily remove it. So I see at least some use where I probably could not argue too much for the use of configuration management.

Installation is IMHO more likely to be done locally when you need a tool (like tcpdump), but I can see a case for removal. That’s actually slightly easier because if you want to remove a package that doesn’t exist or isn’t installed, that’s fine. The end state is that it’s gone, as desired.

The install package dialog can really be pretty hard because of the fact, that even two EL8 hosts can have different content views - it get even worse if 2 hosts of different EL version or even different OS product at all are selected.

To solve this:

  • make sure, that only hosts of the same content view are selectable.
  • remove the install/update package form completely. if you want to install packages for a host, go to the host directly and select the software you want to install. Or, as Ewoud said, use a config management tool do install and configure the application accordingly.

I’m wondering about the various other wizard steps.

In the current host overview I typically search for the hosts, select the ones I want and then perform bulk actions on them. That means the selection of the action already happens before I enter a wizard. That makes step 1 obsolete.

Then we have step 2, install packages. I assume this changes depending on which action is chosen. If we look at the easier cases, namely upgrade we have:

  • Upgrade all packages. Not sure which inputs this would have
  • Upgrade packages. Has a list of packages

Depending on how you want to implement this, you could implement this in a single view wizard and make step 2 a filter/selection. If no filter/selection is specified then all packages are upgraded.

Step 3, review hosts. Because the host selection happens in 1 step 1 I always feel this is is a redundant step, already with REX.

Then there’s step 4, review. How is this different from step 3 and could they be combined?

And you can probably see where I’m going with this: do you need a whole wizard for upgrading packages? If the filter/selection provides a preview of what would happen while selection of hosts and specific action happens prior to showing the dialog then I see just a single step.

Now I’m not a designer so perhaps this violates some UX guidelines but it’s how I’ve learned to use Foreman:

  • Select multiple hosts in Hosts overview → bulk action
  • Go to a Host detail page → single host action

That does mean you want an equivalent action on the Host detail page. Now that is really simple because the dialog doesn’t contain any host selection anyway.

Please note that this wizard was implemented according to the designs from UX, so many of the design decisions are not from developers (which IMO is as it should be.)

Some notes about the way it currently works, and the way I think about it:

  1. You choose an action.
  2. For Upgrade and Remove, you choose the packages from a list.
  3. You can review / take a second look at the hosts you’ve already selected, and optionally remove some from the selection. (this was part of the design from UX)
  4. You can review all of your selections, and then execute the action either immediately or customize your REX job.

‘Upgrade all’ runs “dnf upgrade” without any arguments, so it will update all packages on each host without Katello having to govern which packages to update. Nice and simple.

So where does the list of packages come from?

The ‘Upgrade’ and ‘Remove’ tracks both use the Katello::InstalledPackage model. This includes both debs and rpms. However, it does not scope the list to the hosts you’ve selected. This decision was made for simplicity’s sake, because that query might be quite complicated and slow. Using Katello::InstalledPackage is important here, because that model is assembled from hosts’ reported “installed package lists” and may include packages that Katello doesn’t serve or know about otherwise.

The ‘Install packages’ currently uses the Katello::Rpm model and a new API endpoint created for this purpose, thindex. The reason for this was that we needed to display a list of possible packages, distinct by name, and we don’t need any other info. (The limitation here, obviously, is that Katello::Rpm doesn’t include debs or other packages.) Again, this is not scoped to content view or LCE for the sake of simplicity and speed.

Once you review and execute the REX job, if your input is invalid in any way two things might happen on each individual host:

  1. The Ruby method package_names_for_job_template errors and the REX job fails.
  2. The actual dnf command runs and fails, and the REX job fails.

In any case, I think the wizard is for the user to describe intent, and the really meaty validations and double-checking happens at the individual host level inside the REX job. As long as we keep this philosophy when extending to deb, I will probably be happy.

As to what to do, I’m leaning towards a separate wizard for deb (could be hidden if that content type is disabled), or a toggle in the wizard to show rpms or debs. These options would allow the intent / validations to remain in the right places IMO.

Some interesting UI history: The old version of the UI required you to both know and type the package name.

Asking users to do that IMO is basically the same as sending them straight to the REX job wizard and making them do it themselves. I think having a list of packages to choose from is a much nicer user experience (but again, now we’re dealing with the tradeoffs of that.)

I was looking at it from a user perspective, not a developer. Perhaps I’m not the target audience, but I think the wizard is too many steps

Fundamentally I question how many users would use the wizard. Also, if we look ahead at future developments like containers (especially bootable containers) then aren’t we building something that is a dead end? Just because it was useful a decade ago doesn’t mean it still is useful. I have a hard time answering this, but that’s my general feeling.

This means, that a Redhat Host receives RPM of SuSE CV and vice versa. It would mean, that a user who selected EL8 hosts would receive a package list including EL9 packages. If you have selected one Alma EL8 host and one Alma EL9 host, it would receive all RPMS and its comletely mixed up.

From the user perspective, this is pretty bad I would say. My expectation is, that I only see packages in the list which are installable on the host. Otherwise I would then get a error message after the fail installation attempt.

Am I right?

Sure, in a perfect world that’d be nice. But in this wizard, it’s not just a single host; any number of hosts may be selected. So our options are

  1. Combine the installable packages for the selected hosts, or
  2. show you all installable packages.

With (1), narrowing down the list wouldn’t even provide much benefit, because a package installable on host A may not be installable on host B, even if it’s the same OS. So we went with (2) which is easier across the board. The end-of-line validations are during the individual REX job, and I think this further illustrates why.

some proposals how to fix this issue:

  • Remove Install Packages completely and let users install packages on the host page, with config management tool or by REX
  • if you start a bulk action from X host and you use Install Packages, it is checked whether the hosts have the same CV. if not equal → abort
  • if you start a bulk action from X Host and you use Install Packages, it is checked whether the hosts have the same CV. if not equal → let users remove hosts so that you only have one CV left
  • if you start a bulk action from X host and you use Install Packages, the system checks whether the hosts have the same CV. It will shgow a package list “per CV”.

Long time ago, I have posted how we have used the upgrade function with spacewalk, which we found really useful:

In spacewalk you could select any number of hosts. In the next step you have got presented a list of all packages which can be updated on any of those hosts. You could then select the packages you want to update and then run the update. This updated the selected packages on those of the hosts which have it installed.

We found this very useful, because it allowed us easily to update non-critical packages immediately which don’t interfere with the server operation, e.g. binutils, rsync, tzdata.

In other occasions, when we wanted to update almost everything, we have used it to exclude some packages which we don’t want to update without closer supervision, e.g. gitlab, bareos, elastic or updates which we want to test further before applying them everywhere. That way we could update everything on all selected hosts with those few exceptions.

Currently, for the former we have to notice which updates are available and then start the individual updates for specific packages. And a few additionals we have learned by now, e.g. when a tzdata update is available there is also a tzdata-java update available for a few hosts which use java. But for not so common packages it may go unnoticed at first, which isn’t nice.

For the latter (update everything except…), there is basically nothing at the moment. As long as there is only a small number of updates available, we update those directly via the package page, picking the package which also updates all dependencies. However, when there is a larger number of updates, it gets cumbersome. We basically update the hosts manually or we must take other precautions to exclude those updates we want to delay.

It’s still one of the most missed lists from spacewalk for us: a global list of packages which can be updated on any of the hosts or a specific list of packages which can be updated on selected hosts.

1 Like

what are your thoughts @jeremylenz

Of those options, I would go with a modified third bullet -

  • if you start a bulk action from X Host and you use Install Packages, it is checked whether the hosts have the same CV. if not equal → let users remove hosts so that you only have one CV left

I would be okay with a warning banner on the hosts select (review) step, saying something like

The selected hosts are not all in the same content view environment(s). Packages may not be available to all hosts. Review your host selection and remove hosts here if necessary.

The banner could be persistent on the host select (review) wizard step, as long as the condition persisted.

There could also be a reminder text added to the final Review wizard step.

We’d also probably have to add a ‘content view environments’ column to the host select (review) wizard step.

1 Like

Thanks everybody for the feedback! We will work on Jeremy’s proposal, eventually, to get some Debian integration into the wizard.

2 Likes

I created an upstream issue to track this: Feature #38186: Add Debian support to the new All Hosts --> Manage packages wizard - Katello - Foreman