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