Configuration API

[C. Gatzemeier]

Am Monday 03 May 2004 15:12 schrieb Dave Cridland [Home]:


> > Think the API must be avere of the need of activation on (the config tool
> > users) demand for apps not avare of notifikation.
>
> Again, this is dwelling on the concept that there are multiple backends,

Well there actally are many out there :)  (SCNR)

> which operate a fixed portion of the namespace. I think that might get very
> complex, very fast.
>
> The nastiest possibility is that a backend must be authoritative for two
> non-contiguous portions of the namespace, in which case things would be
> very complex.

Ok, now I can see the case for the point you are making. Declaring one backend 
as authoritative *globaly* in order to solve this comes with unfortunate 
sideeffects though. What was thought about to solve this, and what might be 
an alternative is to have meta-variables that are authororitative just within 
the common config representation.

For example when apache, cups and samba all store some same setting lets say 
"Servername" for a (bad) simplification here. For all apps their own value is 
authoritative, but within a common representation their settings could be set 
to a meta-variable, a common setting like "Servername" that is defined by 
meta-configuration just as the others, but only used for cross reference 
within the representation. The setting is stored in one (arbitrary) backend 
and has only a authoritative meaning on and within the abstraction layer. 
This makes it possible to change the "Servername" in the common API and 
change different apps in one step if their meta-config is set so.



> I'd prefer to see all configuration managed by a single backend. Apart from
> anything else, forcing all Apache configuration to be managed by a
> Config4GNU style chunk of namespace

I wouldn't call it managed by I'd say it can be edited by it.

 precludes the possibility of using a
> network-based central management tool, largely, unless we create a protocol
> on top of the API to handle this - which, in my opinion, is getting well
> over the top, since people wishing to do this will be using a network
> protocol already to manage the config.

If you like please try to rephrase this again, I am not really sure what you 
where refering to here.
I have been thinking that Config4GNU was allways trying to make as less 
assumptions or mandates as possible. There are those two alternatives though, 
to install CFG on each host in a network  (possibly accessible through a 
network protocol frontend) or to let the backend interfaces access remote 
databases/fetch files (ssh) with a network protocol itself. 



> Yes, absolutely. The point I'm trying to make is that Apache, for instance,
> need never know that its configuration is managed by a relatively complex
> configuration system which is unavailable before the network, or /usr, or

Yes, apache or whatever shouldn't need to be aware of it. All "config file 
managed by" approaches I know of couldn't hold true to allways guarantee that 
though, and surely let to conflicts with other tools, that just claim the 
same.  Manual changes and fixes in configuration to solve a boot problem for 
example get overwritten as soon as the "management" overtakes control of it 
again. Administrator's carefully hand crafted scripts can't do its job 
anymore.



> There are, of course, edge cases, such as when a machine's boot-time
> configuration is changed when that machine is offline - or simply off - 

To handle those cases one would have to let the client pull its config (/etc 
etc.) from a server. 



[apps modifying other apps configs]

> Hmmm. Yes, I see where you're coming from.
>
> However, I'd suggest that that leads to applications which ignore the
> policy set by the site administrator.

Err, that is a different problem IMO not somthing that gets solved leaving 
obstacles on purpose.

I agree that
> There's plenty of good reasons to store configuration externally from these
> files
like backups config alternatives logs and diffs etc. but they should be 
considered as authoritative. They can be made authoritative if saved, 
possibly through the common api, at a place where the corresponding 
application considers it to be authoratative. This can be a separate file or 
a common backend if the app so desires in the future. If the user has those 
rights of course.


> There is one key time when an application needs to access two backends at
> the same time, of course - when the administrator requests a change in the
> primary backend used.

Ah, that might be a nice example, yes. I'd rather like to read this as -- only 
when the administrator requests a change in the common (dynamic) 
representation.

Just saying rather make the representatin dynamic than some backends.

Regards,
Christian