[rhn-users] Most Critical Systems list on RHN

[inode0]

On 8/9/06, Máirín Duffy <duffy at redhat.com> wrote:
> Hi John,
>
> Well, I hesitate in adding extra options because of the general
> principle that the more options a UI has, the more complicated it
> becomes. I'm trying to think of a way this widget could be useful to the
> greatest number of people without requiring manual tweaking. IMHO,
> ideally, it would provide you with useful info out of the box.

Fair enough. I'm sure that we are a very fringe case.

> In your example with 5 systems with 300+ outstanding errata... the
> reasons you'd not want them to appear in this list:
>
> * They're 'dead' system profiles (systems that aren't actively checking
> into RHN and may be disconnected or duplicate profiles) and are just
> noise in the list.

An unexpected case of duplicate profiles was one of the items that was
discovered from this in our short experience watching it.

> * You're holding a system back at a particular U-release so you want it
> to not receive those updates on purpose.
>
> I can see a rationale for excluding systems that haven't checked-in in
> say 30 days from the list by default. There is 'not checking in systems
> list' widget on Your RHN specifically to address these systems so
> there's no need to address them yet again in the most critical systems
> widget. (Either way, if you haven't done anything with the system in 30
> days, its critical state is obviously not critical to you. :) ) So this
> is an easy change that would solve the first source of 'false' info in
> the list above.

Exactly.

> For the release-locking use case - an example scenario is that you've
> seen an errata notice, determined the errata was not critical and you'd
> rather not apply it to systems, and you deliberately do not install it.
> But it still shows up as being an available update, creating noise in
> the most critical systems widget.
>
> The way that I suggest avoiding this scenario is treating the
> RH-provided RHEL software channels as your 'upstream,' and 'accept' or
> 'reject' the errata by copying it or not copying it into your own
> software channels. (This is also how I recommend locking a system to a
> particular U-release.) If your systems are registered to your custom
> software channels and you follow this update evaluation process, then
> you shouldn't end up in the situation where an update you don't want
> applied is listed as being available for the system.

This makes sense too but I don't think it could be implemented where I
work. It seems to depend on a satellite for the base channel shifting,
I don't see how to do anything like this in our currently hosted
environment. With widely distributed management of the groups of
systems that we have I suspect we will find managing channels for
everyone on a satellite unwieldy as well. They would never agree on
one way of rolling out updates from Red Hat.

> Does this make sense? Are these suggestions reasonable? Beyond those two
> issues creating inaccuracies, would you still find it useful to tweak
> the widget's settings?

I honestly didn't have anything very specific in mind right now. I am
enthusiastic about the potential for this feature to help
organizations pick off things that may have fallen into disrepair
without being noticed. After hearing how it was supposed to work I
fear that in my organization it might lose its value by fixing on
wildy out of date or back-leveled systems of which there are more than
5 typically. Perhaps that won't happen. I will watch and see how this
feature develops. Thanks for taking the time to share some of the
thinking behind this new feature with us.

John