Bug 128201 - rhn_host_monitoring view broken
Summary: rhn_host_monitoring view broken
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Other
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Fanny Augustin
Depends On:
Blocks: 120996
TreeView+ depends on / blocked
Reported: 2004-07-20 00:50 UTC by Mihai Ibanescu
Modified: 2007-10-24 02:12 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2004-09-13 14:49:58 UTC

Attachments (Terms of Use)

Description Dave Faraldo 2004-07-20 00:50:40 UTC

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.

The Problems

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.

The Fix

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
      ) as
      select  s.id            recid,
              i.ip_addr       ip,
              s.name          name,
              s.description   description,
              s.org_id        customer_id,
              '4'             os_id,
              null            asset_id,
              null            last_update_user,
              null            last_update_date
      from    rhnServerNetInterface i,
              rhnServer s
      where   i.server_id = s.id
      and     i.name = 'eth0'
      select  recid           recid,
              vip             ip,
              description     name,
              description     description,
              customer_id     customer_id,
              '14'            os_id,
              null            asset_id,
              null            last_update_user,
              null            last_update_date
      from    rhn_sat_cluster

   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?

Comment 1 Dave Faraldo 2004-07-20 00:54:46 UTC
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.

Comment 2 Peter Jones 2004-07-20 15:12:58 UTC
Not that I'm an expert on the monitoring stuff, but the view change
looks reasonable to me.

Comment 3 Dave Faraldo 2004-07-20 21:24:56 UTC
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

Comment 4 Dave Faraldo 2004-07-20 21:43:43 UTC
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
with it.

Comment 5 Dave Faraldo 2004-07-23 20:37:20 UTC
To test:  configure a probe against a host and push the config.  If
the config push is successful, the host view is working.

Comment 6 Fanny Augustin 2004-08-05 21:38:24 UTC
Looks good on QA.

Note You need to log in before you can comment on or make changes to this bug.