Configuration API

[Lars Hallberg]

Dave Cridland [Home] wrote:

> On Mon May  3 10:40:52 2004, Lars Hallberg wrote:
>
>> 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, which operate a fixed portion of the namespace. I think that 
> might get very complex, very fast.

Possably, Hovever, if the API is well designed this will all be 
implementation details. We do not need to agree on this to agree on an 
API, and the low level backends can be the same, ether they ar used 
directly as datastore or to synk the config files with a central datastore.

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

Don't think this need be *to* complikated. some central logic (can be in 
a config demon, can be in a lib) maps path to backend and load the 
needed backend on demand (when that namespace is querried), then talks 
to that backend thru the same API, regardless what backend it is.

Some logic probably have to go in the backend - like figuring out hove 
to merge user and system setings from different files/sorces. That 
merging is defiend by the existing apps, and the config must use the 
same roules - it can't define it's own! A good rekomendation for new 
apps will make things easier - but everything will not instantly change 
over!

In the nastest case, the system and user setings is stored in diferent 
file format (silly app that). But that backend can implement both 
fileformats, or load a backend from the backend. Teoreticly the later 
might open up for nasty loops, but in practis this is a prety hierarcial 
strukture.

Possably it is a good idé to have one bakend for the apps logic, that 
loads a different low level backend for the actual file, ldap, ACAP or 
whatever store. All the conections going thru the same API.

This might lead to an actual call will go thru a silly lots of layers of 
the same API. But I think we need that kind of flexibilty to merge a lot 
of config format and a lot of different applikatrion logic in one 
unified API.

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

Over the top or not, the API should alowe this to be an implementation 
detail to.

>>> Potentially, yes. Or they may tacitly or overtly support other 
>>> projects providing these, or they may tacitly or overtly support a 
>>> shepherd process project.
>>
>> Idealy, that would be the same thing!
>
> It should end up being the same result, yes.

Yes, and the same low level backend should do the job in ether case!

> Either way, I think we can safely suggest that any configuration 
> management system with a consistent data model and API would allow for 
> a holistic approach to configuration management.
>
>>
>>>> The benefit from using the API in the app is that it becoms easy to 
>>>> replase the config format or switch between lokal file store and 
>>>> network 
>>>
> config deamons. When a set of solid implementations exists, it will 
> probably be natural chose for *new* apps. But only apps needing som 
> extra features like notification is likly to *change* to use the API. 
> Stuff lika postfix, bind and apache is not likly to be first in line 
> to cross over :-)
>
>>>
>>> Or, indeed, ever convert at all. Bear in mind that it's pretty 
>>> trivial to stuff all the data for postfix's maps into a 
>>> configuration store, but 
>>
> equally, when I looked seriously at doing that, I realised it was 
> easier and better to simply use existing hash files and rewrite them 
> on notifications.
>
>>
>> The nice thing is that they can integrate nicly without ever 
>> converting. As You point out. Ther are strong reasons for some apps 
>> to rely on only on 
>
> files in /etc/. But we still want those apps to be configurable thru 
> our nice new GUI :-)
>
>> A smale point here - if You chose to use the plugin for Apache config 
>> file format directly, You will only gett access to Apache namespace, 
>> but thats good enuf for Apache :-) I can see som use for a small lib 
>> that can load a few backends and present them thru one instance of 
>> the API. That way a app neding to read (and possably alter) a few 
>> config files in different format can do that thru the API without the 
>> need to rely on any config deamon.
>
> 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.

Yes, the exersize was more for apps using the API to using it's own 
configuration. Hopfully, most config tools will go thru som central 
logic, in one way or another.

> There's plenty of good reasons to store configuration externally from 
> these files anyway - for instance, it could allow people to 
> reconfigure their own Apache virtual server *without* being able to 
> reconfigure the whole of Apache, for instance, by use of ACLs.

Well, that the stuff is saved in the same file don't stop the backend 
(or more probably some central logic in the config deamon) from handing 
out more finegraind access controll to the users!

> 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.
>
> Obviously if people edit the files directly while they're being 
> managed in this way, then all hell breaks loose, but the root user has 
> such wonderful scope for letting all hell break loose anyway, it's not 
> a big deal. Indeed, thanks to Config4GNU, you could even register that 
> the modification time has changed, and re-read the configuration 
> anyway, potentially, although that might lead to a race.

Some flush/rescan function should probably be in the API, so You can 
tell Your config system to make sure the /etc/ file is up to date befor 
You su and trhow Your favoprite texteditor at the config file. That 
might be needed when You use the CVS version of Apache and midways in a 
reconfiguration realize that som new featurs You need is not yet 
avalible thru the nice GUI (of corce some simpel key-value pair regestry 
like GUI might do the job to - provided an up to date cheme exist for 
the new featurs).

/LaH