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