[Openais] lcr take 6 - going in soon - last chance for comments :)

Steven Dake scd at broked.org
Fri Jan 27 20:51:47 PST 2006


On Fri, 2006-01-27 at 06:39, Patrick Caulfield wrote:
> Steven Dake wrote:
> > Patrick,

Sorry for not responding earlier - IT problems.

i totally agree with your posting.

> For my own purposes I would like to be able to put the config and component
> code in the same lcrso file. I can appreciate that it would be nice to
> separate them but in many instances but not this one :)

The current architecture allows this quite easily.  It is possible to
define multiple interfaces in one lcrso so the cman config interface and
cman service handler interface could exist in the same shared object
component.  testlib_a and testlib_b demonstrate multiple interfaces
within one object if you want to see how this works.

In order for this to work for either system, we could use an environment
variable override that would do something like this in the init script:
EXPORT OPENAIS_DEFAULT_CONFIG_IFACE="redhat_xml:0".  The aisexec would
read this environment variable to determine the name/version of the
configuration interface to load.  Then this configuration interface
could be used to determine which service handlers to load by default
using the get component/key/value.

This solves the chicken-egg problem of how to configure the list of
service handlers.  We must then ensure default configuration handler
always contains the information on which dynamic services to load.

In the longer term, we could then add a list of configuration interface
handlers to the redhat_xml or openais config iface to be queried when
component/key/value pairs from other services such as you pointed out
LDAP, are available.

On another line of out-loud thinking, we could have in openais a
"configuration database" that could then be populated by the
configuration handlers (vs the reading of the configuration from the
config file handlers).

These two functions would then be passed into the lcrso configuration
file parser interface to populate the internal openais db.

object_create (int parent_object_handle, int *object_handle, char
*object_id, int object_id_len) (object would be returned from this
function)
key_create (int object_handle, void *key, int key_len, void *value, int
value_size);
object_destroy (int object_handle)

Then handlers.h would export this interface just as it does now for
openais handlers.

And then passed to the exec_init_fn would be the functions
object_iterate_init (int iterator_handle, void *parent_object)
object_find (int iterator_handle, void *object_name, int
object_name_len, int object_handle)
object_key_value_get (int object_handle, void **key, int *key_len);  
object_iterate_exit (int iterator_handle)

parent_object would always be 0 for the parent of the configuration
tree.

This allows objects to contain other objects, and for objects or their
children to contain key/value pairs (as long as the keys are unique). 
object names could be duplicated if necessary.

This sort of interface would support parsing of groups.conf,
openais.conf, but I'm not sure about redhat's xml database.  Any comment
on how this would work for the redhat xml database?

OK that hurt - time to eat :)

Regards
-steve




More information about the Openais mailing list