On Wed, 2008-03-26 at 12:36 -0500, David Teigland wrote: > On Wed, Mar 26, 2008 at 10:32:54AM -0500, David Teigland wrote: > > A while back I drew this diagram to show what we were aiming to design, in > > broad terms, for the next generation aisexec/cman config system: > > > > http://people.redhat.com/teigland/cman3.jpg > > > > I think perhaps that diagram attempts to do too much, and I've drawn > > another: > > > > http://people.redhat.com/teigland/cman3b.jpg > > > > The big problem I see with the first diagram is that it tries to use objdb > > to solve the meta-configuration problem [1]. That's a hard problem, I'm > > not sure objdb is the right place to solve it, I don't think we have > > enough information to solve it properly right now, and I don't see that we > > have a pressing need to solve it right now. So, the second diagram steps > > back to what Fabio has already implemented, more or less. > > There were quite a few things wrong in the cman3b diagram, so based on the > explanation from Chrissie and Fabio, here's another: > > http://people.redhat.com/teigland/cman3c.jpg > > (The "assumes" comments don't mean it would be impossible to use one lib > with a different config plugin, but that it wouldn't make sense to do so > in practice.) >
This diagram indicates there is a need for two separate levels of datahiding. The first level is the libcsdb (corosync db) which then some other library parses for information specific to the cluster stack. Then this other api is used. In my mind this type of double abstraction serves no purpose. They both serve up the same data. It also may result in the loss of one of the effects I'd like to achieve with all of this work which is : standardizing the object database format, layout, config options that are generic If only rhcs's cluster configuration is aware of certain config options, then they are not generic and not usable by others. This should be avoided. > > Lon pointed out another problem with the first diagram, and that's that we > > want to be able to read config values without openais running, and running > > properly. That's one of the things we were trying to get away from with > > ccsd. > > The cman3c diagram does not solve this problem, but it could by caching a > local copy of the config data to use when aisexec is not running. > Caching these values is not suitable in my opinion. Just use the rest of the infrastructure we already have in place to parse them and put them in the objdb and make them available via some unnamed api. Since everything is a plugin it is possible to write code to query values directly. So the query-without-aisexec running would load the objdb plugin, and would also load the config parser. The config parser architecture and objdb plugin as they exist today would remain unchanged. The only changed part would be the new "main.c" which plugs these components together for the purposes of reading this config data when aisexec is unavailable. Regards -steve _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
