Re: [Openais] new config system
David Teigland wrote: On Wed, Mar 26, 2008 at 12:24:23PM -0700, Steven Dake wrote: 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 Right, libcsdb isn't doing anything, scratch it out. I just added it because Chrissie suggested another lib in there might help. The main reason for the double library was to avoid linking libxml with an openais component. While I'm clear (and heartly agree) that large external libraries should not be part of the exec I had a bit of a hard time getting a clear policy for IPC-based libraries. I'm not wedded to either solution, I was largely hedging my bets. 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. Fine, scratch that too, it's not important. I'm not going to push this either way at the moment, but I think we should keep in available as an option. It might be helpful as an emergency fallback to get a cluster up where there is no other way of getting configuration information. -- Chrissie ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] new config system
Hi Wouldn't this be solved quite well with the AIS-IMM interface? Obvously it hasn't been implemeted, but if you implemented a subset of the interface you could get what you are after and we could all benefit from more of the AIS spec been implemented. Initially you could make use of the ImmOi (Object Implementer) interface. P.S. : I am just starting work on this. Regards -Angus ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] new config system
On Wed, 2008-03-26 at 10:32 -0500, David Teigland wrote: [1] Just to be clear, the meta-configuration idea is where a variety of config files can be used to populate a central config-file-agnostic respository. A single interface is used by all to read config data from the repository. Even if we did this, I don't see what it would give us anything. All our existing applications access data that's only specified in a single config file anyway, so interchangable back-end files would be an unused feature. True, it doesn't give _us_ much to be agnostic to what the config file format looks like. However, with different back-ends used to populate the single config repo at run-time, we then have the ability to not have config files at all (well, except the meta-config stuff). What I mean is: An administrator might like to store the cluster configuration in an inventory database which isn't local to the cluster itself (e.g. LDAP, or whatever). This might not be a requirement now, but that was one of the points of having multiple config back-ends, IIRC. I guess there's no reason that we couldn't cache a local copy of the configuration... *shrug* -- Lon ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] new config system
On Wed, Mar 26, 2008 at 11:57:59AM -0400, Lon Hohberger wrote: On Wed, 2008-03-26 at 10:32 -0500, David Teigland wrote: [1] Just to be clear, the meta-configuration idea is where a variety of config files can be used to populate a central config-file-agnostic respository. A single interface is used by all to read config data from the repository. Even if we did this, I don't see what it would give us anything. All our existing applications access data that's only specified in a single config file anyway, so interchangable back-end files would be an unused feature. True, it doesn't give _us_ much to be agnostic to what the config file format looks like. However, with different back-ends used to populate the single config repo at run-time, we then have the ability to not have config files at all (well, except the meta-config stuff). What I mean is: An administrator might like to store the cluster configuration in an inventory database which isn't local to the cluster itself (e.g. LDAP, or whatever). This might not be a requirement now, but that was one of the points of having multiple config back-ends, IIRC. That's what I had in mind with the other? arrow pointing up at libcmanconf. Multiple back-ends for libcmanconf is one thing (good, simple); multiple back-ends for a meta-configuration database with a meta-API is what I've become skeptical about. ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] new config system
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.) 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. ___ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
Re: [Openais] new config system
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
