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

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

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

All,

Have finalised the object definition for dynamic_template objects. It is the
same as above except that the contact option has been removed. We don't need
this as all hosts/services rely on contact groups as their notification method.

So to confirm, the initial object proposal is

define dynamic_template{
  
  remote_template_name  db_server
  uses_host             name_of_host_template_from_hosts.cfg
  runs_services         comma_seperated_list_of_services_from_services.cfg
  contact_group         contact_group_from_contact_groups.cfg
  joins_hostgroup       hostgroup_from_hostgroups.cfg
}

I've updated the current XODTEMPLATE system to deal with this new object type.
These objects are not registered with objects.java as with every other in blue,
they are instead registered with RegistryObjects.java. This is so we can maintain
a level of isolation between the registry and Blue.

Something we need to discuss is where the details of objects that are used as
part of a dynamic_template definition are stored. For example, I define that
my dynamic_template uses_host
generic_remote_host from hosts.cfg. This host will be a template and not a "real"
host and therefore will not be stored into objects.java. My current thinking
is that we maintain a host, service, contactgroup list in RegistryObjects along
side the list of dynamic templates. We also extend the current object model
to include an attribute called dynamic_only. If any object definition includes
the dynamic_only attribute, it is stored into the RegistryObjects.java stores
rather than being registered with Objects.java.

Once the XODTEMPLATE process is complete, the registry will have a knowledge
of all templates available to it and the hosts/services that make up these templates.
When it receives a request to register, it simply walks the attributes of the
dynamic_template object i.e

-> grab host name ==> write out properties to .cfg file
-> grab services we run ==> write out properties to .cfg file
-> update host + services with correct contact group
-> update host with correct hostgroup information

->write file + write to external command file
 -->ADD_DYNAMIC_RESOURCE;my-new-config.cfg 
 -->ENABLE_HOST_CHECK;my_new_host

I propose that each .cfg file generated in this manner, the name consists of
a timestamp and the remote IP address of the host wishing to register.

Rob

______________________________________________________________________
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