[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netsaint-devel
Subject:    [netsaint-devel] NetSaintConfDB, PostgreSQL "LISTEN" and "NOTIFY" (Was: Re: xoddb)
From:       karlheg () microsharp ! com (Karl M !  Hegbloom)
Date:       2001-07-27 17:01:26
[Download RAW message or body]


>>>>> "Randy" == Randy OMeara <OMeara> writes:

    Randy> It looks like you've done some of the preliminary work
    Randy> to allow NetSaint to support objects defined in an external
    Randy> DB.  I may have a chance to take a look and possibly extend
    Randy> the work you've already done.  What is your licensing model?

 Yes.  I started with "NSA", the "NetSaint Administrator", which is a
 PHP application that uses a mySQL database.  It was not usable as-is
 for our purposes, so I snabbed their idea, and created
 NetSaintConfDB.  I chose to implement it in Perl, using the Tangram
 object persistance system to manage a PostgreSQL database. (Tangram
 handles the database via DBI, of course.  It would work with mySQL
 just as well, perhaps.)

 How about LGPL or Perl Artistic?  Notice that NetSaintConfDB has no
 user interface, just the middleware layer.  I'd like to (help) make a
 Perl-GTK (via Glade, from the Gnome project) interface for it at some
 point.  A WWW interface and command line tools can be done also,
 using the NetSaintConfDB module.

    Randy> Using a trigger from PostgreSQL to notify NetSaint of pending
    Randy> host/service/command/etc changes is a definite possibility if
    Randy> NetSaint can be made to incorporate just those changes rather
    Randy> than re-read its entire configuration and start fresh.

 Right.  I thought that the LISTEN and NOTIFY features of PostgreSQL
 could be used something like this...  (anyone got experience with
 designing, implementing, and using systems like this?  Please speak
 up and help us.  This is the first time I've even thought over a
 problem like this one.)

    Karl> In "NetSaintConfDB", I've got a "under creation" flag (ala the RMON
    Karl> Polka, if you know what that is) and a "logically removed" flag that
    Karl> are meant for doing this.  The monitoring engine could perform two
    Karl> selects, and find out what to remove, what to add, and what has
    Karl> changed.

  $Netsaint connects to the configuration database, and issues a
  LISTEN.  The configuration UI, after making a set of changes, issues
  a NOTIFY, and that signals $Netsaint, and it:

  Perform a SELECT and get a cursor on all items in the database that
  are flagged for removal, walk them, and tag the same items it's
  holding in RAM.  Tag them, don't free them yet.  The flight check
  will pretend that tagged items are not there, and if the flight
  check is successful, $Netsaint can garbage collect them at that
  point.  The flight check should not happen just yet though...

  Next perform a SELECT and get a cursor on all items flagged as
  "UNDER_CREATION".  These are newly created records.  To modify an
  object, mark it as both removed and under creation?  I need to think
  this over some more...

   The thing is that if the UI is implemented in a stateless
   environment such as CGI where multiple Apache child processes are
   involved, and thus multiple database transactions are involved,
   (BEGIN WORK, COMMIT), it can't just NOTIFY right after the COMMIT,
   since a change to one object or to everything presented on one
   screen of the UI is not necessarily a logically complete or
   internally consistent change for $Netsaint's point of view.  In
   that environment, you have to provide an "apply changes" button.

  That is why there is an "under creation" flag and a "logically
  removed" flag.  (as well as a "disabled entry" flag; don't use it
  but don't purge it from the database either so an operator can
  re-enable it later)

  Another problem occurs when there is more than one operator
  interacting with the system.  Operator A opens the UI and starts
  editting something.  She commits the first form, then before
  commiting the second one, gets a phone call.  In the meantime,
  operator B opens the UI and makes a change, then goes straight for
  the "apply changes" button, and logs out after seeing the green
  lights.  Operator A gets off the phone, and finishes making changes
  then clicks "apply changes".

  Right now what I do is unset the under creation flag for everything
  owned by a certain login, then call an exportconf routine that
  prints a hosts.cfg file.  If the flight check fails, I roll it back
  to the old hosts.cfg and retag all of those as under creation again.

  If $Netsaint does its own database configuration importing, it's got
  to deal with that situation somehow, sanely.

  I've thought that perhaps a multi threaded implementation would be
  good... another idea is to have a Perl script deal with the
  database, like it is now, but instead of writing a hosts.cfg that
  $Netsaint must parse, it could build a binary .so somehow and
  $Netsaint could just dlopen that.  The flight check could be done by
  a separate process.  But that gets complicated.  Would it interrupt
  the monitoring engine for less time to close then reopen a .so,
  rather than parsing a conffile?  Seems like it would.

  Enough daydreaming... I've work to do.  TGIF!

    Randy> The trigger mechanism could even generate a command to
    Randy> be given to NetSaint's external command interface... if
    Randy> NetSaint could accept host/service/command/etc definitions,
    Randy> modifications, and deletions through this interface.  That
    Randy> capability does not exist at present.

 I thought of that also, but have not really spent much time thinking
 about how it should work.

-- 
mailto: (Karl M. Hegbloom) karlheg@microsharp.com
http://www.microsharp.com
phone://USA/WA/360-260-2066
jabber: karlheg@jabber.org

_______________________________________________
Netsaint-devel mailing list
Netsaint-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/netsaint-devel

[prev in list] [next in list] [prev in thread] [next in thread]