[Blue-devel] [blue - Developers] Auto Inventory

[SourceForge.net <no...@so...>]

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=4160935
By: akuns

Rob posted a great docuement at
http://sourceforge.net/mailarchive/forum.php?thread_id=31657840&forum_id=48489
to get started on discussing the topic of 'Auto Inventory'.   Today there is
no concept in the design for adding inventory components.

The 'hacks' I could see on the existing architecture would be to manipulate
the config files, specifically using the cfg_dir option.
Set this to a directory called etc/dynamic and manipulate files in this system.
Well if we go that route how would the system reconfigure itself?  When a file
is written you would need to restart server to reprocess configuration files.
This could cause some strange behaviour and some danger in potentially reading
files as they were created or deleted.  The system itself is pretty solid in
this regard as information about the schedule is persisted and can be reused.
Though it reloads the inventory I don't believe it means the server in-essence
starts from scratch.

Second hack bolt something on to use the internal APIs.  If we add something
on to blue to listen to messages (ie. jmx, http, ...) we could manipulate the
objects through org.blue.common.objects class.  This is what is use by the template
configuration system to add/remove/manipulate the inventory on startup.   The
question would be how to persist things?  The system technically persists it's
state, and on restart could be configured to use that state. Hence changes do
persist, but they are not reflected in the actual template system.  Though this
might be achievable if we add methods to the template system to understand
persistence.  (Would not want to add to other places as it we eventually want
to make the inventory repository pluggable.

So... there are three components this problem.
A. how does is the system notified in new/changes to the inventory
B. how does the system change the in memory map of inventory and what happens
because of that
C. how does that get persisted.
(some might flip B and C, how is it first persisted and then recognized by the
in-memory model.

1. B the controller gets a message "please add host". 
So who does B tell, and what does it tell it?
B tells org.blue.common.objects. ADD NEW SERVICE, REMOVE SERVICE, UPDATE
SERVICE?
** this is the first question we must tackle, and is this right order?  who
gets notified first : persistence engine or model?
  


We are also going to have to address the model at some point so here is
a summary.
* timeperiod
* command
* contacts
* contactgroup
* host
* hostgroup
* hostescalation
* hostdependency
* hostextinfo
* service
* servicegroup
* serviceescalation
* servicedependency



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=545812