Fedora.next: I would like working configurations

Alek Paunov alex at declera.com
Tue Jan 28 23:49:42 UTC 2014


Hi Stephen,

It is clear that OpenLMI (optionally plus D-Bus bridge) will be our 
"native" ;-) configuration mechanism.

But as I read the Oron's concept, it perfectly maps to the CMDB part of 
the WBEM/"high-end" approach, so I like it very much (*).

I.e. what Oron describes as "database" is the persistent, consolidated 
model of the _desired_ future state of the things, since the API set 
(including Augeas) provides 1) current state determination and 2) 
step(s) methods to reach that desired state.

Next, the role wizards (and possibly other interfaces) comes to "fill" 
the model roughly like how Anaconda interactively prepares its internal 
kickstart model, before installation start.

What in your current vision represents the desired state?

Two more notes bellow ...

On 28.01.2014 15:23, Stephen Gallagher wrote:
> On 01/27/2014 07:35 PM, Oron Peled wrote:
>> On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote:

...

>> * A package installation register its configuration options in a
>> system-wide "database".
>
> I'm not sure this makes sense. This would require us to maintain data
> in two places, because zero existing packages would *retrieve* their
> data from this location. We'd have a duplication problem and we would
> also be responsible for bi-directional sync (if someone hand-edited a
> configuration file, we'd need to read it back into the database).
>
> I think it makes more sense to build an API around something like
> Augeaus and rely on being able to read and write the configuration
> that the packages already understand.

IMHO, Augeas is all about the seamless bi-directional sync with 
something unified - i.e. more manageable ;-), Augeas do not know 
anything about the semantics of the text.

So, as you say API without secondary DB, that perhaps means that the 
whole semantics (i.e. enough about the objects inside services) should 
be encoded in _imperative_ fashion in e.g. Python (or may be you have 
something clever in mind, like common engine over ... ?)

OTOH, the API over reasonable DB implementation means only schemes 
(ideally reusing the CIM ones), Augeas paths/Schema mapping, and ideally 
rules. I.e. only _declarative_ elements, which in turn leads to more 
agile development, easier support and if we have some luck :-) - help 
from the upstreams and other distributions and OSs.

I have some crazy ideas e.g. to write syslinux lenses and "fake" PXE 
tree with FUSE :-). I.e. why not talk with (not yet manageable 
otherwise) services in their current way - as supporting dynamic view of 
their configurations (FUSE or inotify triggers) - keeping the comfort of 
the experienced sysadmins to edit the "text" configurations (similarly 
of what does "virsh edit" now).

...

> Again, if we build a sensible API, it should be possible to build
> whatever presentation layer we want to atop it. Of note, we're
> planning to work with the Cockpit Project for our reference
> implementation.
>

BTW, perhaps we should try this at home :-)?

https://github.com/cockpit-project/cockpit/blob/master/HACKING

>
>> * All front ends need only understand the generic types of the
>> options. (I.e: they provide generic configuration UI widgets which
>> aren't modified when new packages/options are added)
>>
>
> I don't agree with this. Providing just a text entry box and a
> description isn't an effective UI technique, particularly if you want
> to be able to produce guided or wizard-based operation. (For example,
> if you have branching decisions during configuration).
>
>
>> * The debconf "API" allows fetching any option from the database
>> and the values of these options are used to configure the actual
>> software.
>>
>
> See above for the sync problem with this.

Oron says DB.desired -> Managed Thing, the sync problem is Managed Thing 
-> DB.current, but this not seems so serious problem, see the crazy idea 
above :-).

Kind Regards,
Alek

(*) With single remark: I think it will be even better if the "database" 
covers more than one instances, because the instances are often tightly 
integrated nowadays (all containers, office range services, the whole 
datacenter).

P.S. Reading Oron's mail, I googled OpenLMI+CMDB in attempt to catch 
something about the current plans in that regard, but instead found some 
SUSE ideas on our hot :-) topic (slide 39):

https://www.suse.com/events/susecon2013/sessions/presentations/FUT1432.pdf



More information about the server mailing list