The monitoring system requires that we have an IP address for every
monitored host, represented in the HOST table. Since RHN servers
can have multiple ethernet interfaces (listed in the
rhnServerNetInterface table), we decided that we would pick a
reasonable default and allow the user to change the monitored
interface if they desired. The rhn_host_monitoring view was
designed to represent the HOST table, with the
rhn_interface_monitoring table representing the user-selected
monitoring interface. However, we failed to plan UI around this
feature, so the rhn_interface_monitoring table is unpopulated.
Also, when desiging the Triumph release, we declared that monitoring
scouts would always be to be RHN-managed servers (i.e. represented
in the rhnServer table), and planned appropriately; in particular,
we added an rhn_server_monitoring_info table to the
rhn_host_monitoring view to differentiate between scouts and
monitored hosts. However, we hit a snag when we realized that
Management Satellites don't generally manage themselves, so a scout
that is also a Management Satellite will not appear in rhnServer in
its own database. We then made the call that scouts would be
independent entities without records in the rhnServer table.
We now have two problems related to the rhn_host_monitoring view:
1) As the rhn_server_monitoring_info table is not populated, no
managed servers can be monitored.
2) Scouts are not represented in the view, and so cannot be monitored.
1) The fix we (dfaraldo, gdk, kja, & nhansen) came up with for the
first problem is to pick an interface for the user. (Suboptimal,
but it will have to do.) I have checked a new definition of the
rhn_host_monitoring view to implement the fix:
Note that the new view selects only 'eth0' for monitoring. Unless
we can safely assume that all managed servers have an eth0, it would
be better to choose any existing interface (say, the lowest-numbered
ethernet interface) ... but my SQL-fu is not that strong. Any
2) I have not attempted a fix for the second problem, but here is what
I propose; let me know if I'm smoking the really good crack.
2a) Change the rhn_host_monitoring view definition thus:
create or replace view rhn_host_monitoring
select s.id recid,
from rhnServerNetInterface i,
where i.server_id = s.id
and i.name = 'eth0'
select recid recid,
2b) Make rhn_sat_cluster.vip a required field representing the IP
address of an interface on the scout;
2c) Have the rhn_sat_cluster/rhn_sat_node creation logic take new
recid's from the rhnServer id sequence to avoid recid collisions.
What do you think?
BTW, I did not apply this schema change to webdev (or check in
dbchange xml for it). We'll need to do that when the view is finalized.
Not that I'm an expert on the monitoring stuff, but the view change
looks reasonable to me.
1) is in for 350 sat; we will monitor the eth0 interface for now.
2) is being deferred to 360, where it will require code changes to the
scout record creation logic, installer logic, and UI as well as the
schema change. Passing to gdk for break-out, prioritization, and
Hmmm ... On second thought, I'll create a second bug for 2). 1)
involves a schema change for rhn350sat, so we need a bug to associate
To test: configure a probe against a host and push the config. If
the config push is successful, the host view is working.
Looks good on QA.