[rhn-users] Most Critical Systems list on RHN

[Máirín Duffy]

Hi John,

inode0 wrote:
> The thing is that it has been fairly useful so far doing whatever it
> has been doing and I'm afraid it would not be useful if it told me
> there were 5 systems with 300+ outstanding errata. Those systems
> likely don't exist in reality, or are being held a rev back for some
> reason, etc. This is why I think the ability to help focus the
> criteria at the organization level would be really cool. I'd like to
> ignore systems with X or more outstanding errata, systems that haven't
> checked in for more than Y days, etc. Just food for thought.

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.

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.

* 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.

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.

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?

Thanks,
~m