[Katello - 3.15] - Multiple content hosts selected - pick what updates to install globally

Support
,
#1

Problem
Hi guys,

we’ve just migrated from Spacewalk to Foreman+Katello, so I’m kinda new to this environment, don’t throw to many rocks :slight_smile:

Expected outcome:
Select multiple hosts from Hosts/Content hosts, and then have a list of updates available for all hosts and be able to pick what updates to deploy next.

This was a cool feature to spacewalk, usually I selected lots of VM’s and choose “available updates”.
On the next screen I was presented a list of updates and so I was able to select all the files or just a few to push to update.

Is there a was to achieve this using Katello ? If I select multiple hosts the single option I have is this

Screenshot-20200615172056-904x428
Screenshot-20200615172056-904x428904×428 22.6 KB

Foreman and Proxy versions:
foreman: 2.0.1
katello : 3.15.1

Distribution and version:
CentOS Linux release 7.8.2003 (Core)

2 Likes
#2

There is still nothing like that in Katello. I asked something similar here two years ago when I first evaluated Foreman/Katello as spacewalk replacement. Until now there is nothing. A package list for multiple hosts would be really useful for the update and remove function.

Some kind of little improvement is the Content - Packages list when you select applicables. That helps to identify what is available for updates. Yet, you cannot select packages there to update nor is it very helpful if you have a larger number of available updates.

So far, it seems the way to do it with Katello would be to use content views and lifecycle environments and use update all, test and check it, and then promote the content view to the next step…

#3

That’s a bummer, it helps a lot when it comes to very large number of vm’s where you don’t want to apply all the updates at once.

Is there a way to apply for some feature requests? Maybe if we bump it enough the devs will take it in consideration

#4

The answer of “you could probably rig something with hammer” is still the best available option I’d say. I do think this could be convenient feature though.

I haven’t used Spacewalk before, so when you select “available updates” for a number of hosts, does how does it separate out the updates by host? Do you just get a list of packages that are labeled with their respective host?

If you’d like to put in a feature request, I’d say the most impactful way is to enter a new feature here: Overview - Katello - Foreman

When you enter something in our bug tracker, a group of Katello devs are guaranteed to look it over during our next weekly triage meeting. If it’s the first time we see a feature request it’s more likely that it’ll be put on the backlog, but if more people request the feature then it’ll naturally go up in priority.

#5

They do it in several steps:

  1. First select the hosts you want to use (conveniently choosing them from the view of all hosts which have updates pending).
  2. Then you can choose to run Upgrade on those hosts. This takes you to a list of packages you can upgrade. It lists the package name and version and the number of systems which have that package installed.
  3. That takes you to the confirmation page: it lists all the systems which will receive updates and the packages on each system to be updated.
  4. You confirm it and spacewalk will schedule the updates.

This way you can get a quick overview which packages need to be updated. For example, you may pick “harmless” updates like binutils which you know not to interrupt the servers to install while to skip updates of others like tomcat which would result in a service restart and interrupt.

Or you could update everything except that one application which you want to test carefully on a test server only before updating the production server.

1 Like
#6

This is exactly how we used Spacewalk, it is a very handy way to update multiple machines and be sure that you don’t interrupt critical processes or maybe postpone some updates for later push.

#7

By the way: it works in similar fashion for remove: when you choose to remove packages from those hosts it lists all the packages which are installed on any of those hosts and the count of systems for each package. You pick the packages to remove and you’ll see a list of systems and which packages are going to be removed for confirmation before you schedule the task.

Of course, spacewalk doesn’t bother with dependencies at that point, for example, if you accidentally remove a library package you think you don’t need but some other installed package depends on it, the dependency will be gone, too. That is something that might be very useful here, if it’s not too much trouble to analyze the dependencies: the confirmation page should warn about dependencies which are going to be removed…

#8

Just opened a feature request.

1 Like