[Aaron-devel-cvs] CVS: aaron ROADMAP,1.1,1.2

[Sean C. <the...@us...>]

Update of /cvsroot/aaron/aaron
In directory usw-pr-cvs1:/tmp/cvs-serv28508

Modified Files:
	ROADMAP 
Log Message:
Updated ROADMAP (used text-mode in emacs).

Noted docs/architecture for program layout


Index: ROADMAP
===================================================================
RCS file: /cvsroot/aaron/aaron/ROADMAP,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** ROADMAP	2001/06/27 02:21:57	1.1
--- ROADMAP	2001/06/29 08:53:42	1.2
***************
*** 1,61 ****
  $Id$
  
! Ahh the joys of software development.  Here's an ordered list of
! things that need to happen, some can be accomplished in parallel.
  
! 1) Need to have people attack the configuration files, flush them out,
! expand on them, and add more protocols and services.  Out of this an
! architecture can be developed to accommodate the monitoring of various
! services.
  
! 2) After sufficient work has been done on the configuration files, an
! API needs to be defined to allow the central monitoring engine to
! perform a query, interpret the results, and perform an action.
  
! 3) A central monitoring engine needs to be developed that'll be able
! to (note: process = thread for now):
  
!   *) fork and dispatch a worker process that'll perform the
! queries and actions.
  
!   *) monitor workers to make sure they don't grow too large, violate a
! site policy, etc.
  
!   *) fork and dispatch an analytical process that'll run periodically
! to test for SLA violations, or perform some offline AI functions based
! on the data at hand.
  
!   *) fork and dispatch a report process that'll be able to respond to
! queries regarding the status of both services and the aaron service.
  
!   *) fork a child that'll be capable of streaming out information
! about what is being monitored and the status of what is being
! monitored.  Ex: machines checking each other at different geographic
! locations.  Ex: multiple machines in a location checking the services
! at a 2nd off-site location, etc.
  
!   *) kill workers on shutdown of the aaron service
  
! 3) Develop the modules that'll run with their appropriate
! configurations (see MODULES_* for a list of complete or desired modules)
  
! 4) Release a 0.5 version of the software to Freshmeat
  
! 5) Bug fixes and module enhancements 0.6
  
! 6) Refine the API and configuration syntax.
  
! 7) Use iterative software development cycle to 1.0.  Version 1.0
! should still be written in the prototype language.
  
! 8) Begin the move from prototype language (probably scripted) to C.
! Port all tier one modules and core monitoring engine.  Before 2.0 can
! be released, aaron must:
  
!  *) compile and run on all tier 1 supported operating systems (see OS
! for details)
!  *) compile and run all tier one modules
!  *) compile and run most tier two modules
  
! 9 and beyond) Incremental support for more operating systems and
! modules.  Release new versions as appropriate.
\ No newline at end of file
--- 1,75 ----
  $Id$
  
! Here's an ordered ROADMAP of events that need to happen.  Some of
! these can be accomplished in parallel.  See doc/architecture for
! the architecture of aaron.  This ROADMAP is subject to change based
! on the new program layout specified.
  
! [config] Need to have people attack the configuration files, flush
!   them out, expand on them, and add more protocols and services.  Out
!   of this an architecture can be developed to accommodate the
!   monitoring of various services.
  
! [devel] Load configuration files.  Configuration files should be
!   parsed.  An event handler should be dynamically load the appropriate
!   module and have the newly loaded module extend the XML parsing class
!   at module load time.  The newly loaded module registers additional
!   event handlers that are applicable to the rest of the config file
!   and deeply nested nodes.
  
! [api] After sufficient work has been done on the configuration files,
!   an API needs to be defined to allow the central monitoring engine to
!   perform a query, interpret the results, and perform an action.
  
! [devel] A central monitoring engine needs to be developed that'll be
!   able to (note: process = thread for now):
  
! [devel] Fork and dispatch a worker process that'll perform the queries
!   and actions.
  
! 	[devel] monitor workers to make sure they don't grow too
! 	  large, violate a site policy, etc.
  
! 	[devel] fork and dispatch an analytical process that'll run
! 	  periodically to test for SLA violations, or perform some
! 	  offline AI functions based on the data at hand.
  
! 	[devel] fork and dispatch a report process that'll be able to
! 	  respond to queries regarding the status of both services and
! 	  the aaron service.
  
! 	[devel] fork a child that'll be capable of streaming out
! 	  information about what is being monitored and the status of
! 	  what is being monitored.  Ex: machines checking each other
! 	  at different geographic locations.  Ex: multiple machines in
! 	  a location checking the services at a 2nd off-site location,
! 	  etc.
  
! [devel] kill workers on shutdown of the aaron service
  
! [modules] Develop the modules that'll run with their appropriate
!   configurations (see MODULES_* for a list of complete or desired
!   modules)
  
! [pr] Release a 0.5 version of the software to Freshmeat
  
! [devel] Bug fixes and module enhancements 0.6
  
! [devel] Refine the API and configuration syntax.
  
! [devel] Use an iterative software development cycle to 1.0.  Version
!   1.0 should still be written in the prototype language.
  
! [devel] Begin the move from prototype language (probably scripted) to
!   C. Port all tier one modules and core monitoring engine.  Before 2.0
!   can be released, aaron must:
  
! 	[devel] compile and run on all tier 1 supported operating
!           systems (see OS for details)
! 	
! 	[modules] compile and run all tier one modules
! 
! 	[modules] compile and run most tier two modules
! 
! [devel/modules] Incremental support for more operating systems and
!   modules. Release new versions as appropriate.