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

[Patrick Caulfield]

Steven Dake wrote:
> 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.

Great, thanks.

> 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.

Yes I like this.

> 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?

As it currently stand it would need some work on the CCS side. Annoyingly CCS
is stateless and so has to work with complete XPATH paths all the time - so it
would have to remember that the parent of "/clusternodes/mynode/nodeid" is
"/clusternodes/mynode". This could be worked around in a wrapper library
(which we'd need anyway) but I'll have a word with the people in charge of
this and see if I can get it changed - cos it would be nice anyway!

-- 

patrick