Background  
----------

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:

    
http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/rhn/sql/rhn/views/rhn_host_monitoring.sql.diff?r1=1.3;r2=1.4;cvsroot=RHN;f=h

   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
   suggestions?


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
      (
              recid,
              ip,
              name,
              description,
              customer_id,
              os_id,
              asset_id,
              last_update_user,
              last_update_date
      ) 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'
      UNION
      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?