Josh England wrote:
making administration of a large
group of machines a natural extension of administering a single machine
without the need for a configuration language.
[Devil's advocate mode.]
While this is good in terms of teaching existing sysadmins to use
OneSiS, the single language model allows less skilled staff (front line
support in our case) to edit a single common format that they understand
and have the agents do the hard part of understanting dhcpd.conf, DNS
zone files or sendmail.cf (yes you can get impedence mismatches).
Making a GUI that can then edit this single declarative language is then
significantly simpler than one per format. The agents only need to write
the native per daemon/application config files with a template engine.
The read phase to show the user the current state of the configuration
data comes from the profile that's in the single declarative language.
(Yes this means that you can't jump in and edit the native files by
hand, yes it's annoying at times).
Metadata in the schema details for a component could even be used to
triger daemon specific help (or even GUI layout) in the GUI (no we don't
have one that does this yet but it could be done).
In the end it depends what you are trying to do. Existing sysadmins will
probably like the OneSiS model, new Sysadmins coming from something like
Windows server admin might have a different view.
I believe oneSIS can be an excellent starting point to
accomplish the goals of the "Stateless
From what I can see there are maybe a handful of projects out there
that have made significant progress in this area which is great.
Hopefully the lessons learned from each project can be carried forward.
I certainly think this is an area were different options and approaches
is very imporant. Vendor lockin to configuration engines/methods is