* Joost Mulders <Joost.Mulders at sun.com> [2008-03-08 00:46]: > > On Mar 7, 2008, at 7:04 PM, James Carlson wrote: > > > > >> What's wrong with an /etc/something.something file? Such files can > >> easily be edited, grep'd, compared, backup up, copied, saved, moved, > >> commented etc etc. All these nice features are at least more > >> difficult > >> when the properties are in SMF. > >> > >> So, my 2 cents on the question > >>> Which way is the SMF community going? > >> is that it shouldn't become a repository for application properties. > > > > That's the part of your response that I find baffling. I don't think > > that's quite true ... unless I've greatly misunderstood what SMF is > > supposed to be about. > > > > I agree that complex and detailed configuration (think: BGP policy in > > Quagga) likely has no place in SMF because the semantics just aren't > > rich enough, but surely basic configuration parameters for the system > > services do belong there, right? > > > > Or are all of the projects that've placed those parameters there > > already (such as Greenline's changes to inetd, or the routeadm > > changes), and the ones that plan to do it in the future (NWAM at one > > point was talking about it for interfaces), and the original SMF > > project itself (which discussed migrating configuration over time) all > > misguided? > > Probably I am misguided but .. in the 2002/547 ARC isn't anything that > says that application configuarables should go to SMF. I think the > desire to put every configurable in SMF's repository is of a later > date or undocumented. Page 5 of the final materials to 2002/547 says
"In contrast to efforts such as GConf or the Windows Registry, Greenline is not proposing its repository as a general application data repository. Service configurations will move gradually to the Greenline repository; new services are expected to place their data in the repository if possible." But what I wrote earlier in the thread still holds as well: there is no desire to include every application configurable in the service configuration store. > I am not saying all these projects are miguided. I expressed my > concerns as a user, which is what I am. Properties in SMF's repository > limit me as I can't grep, zip, zap, copy, comment them. > The advantages (snapshot & rollback) don't outweigh. IMHO, there's > only one driver I see fit for a central configuration repository and > that is an administrative GUI. See http://opensolaris.org/os/project/vpanels among other efforts. > Obviously, I am just too late with raising my concerns. No big deal. > I'll eventually learn to live with svccfg as I did with regedt32, > regedit, smit*, sam, and odm*. But, after investing my time in > learning them, I ask: what have they done for me, apart from being in > the way? Others raised the same concerns as you during architectural review. If you don't believe that the capabilities that the additional metadata allows us were worthwhile, that's fine. There are studies of availability improvements resulting from the FMA and smf(5) features being present--these were measurable and can be translated to economic equivalents by system users. (For an individual user, that benefit may be small; for others, not small.) - Stephen -- sch at sun.com http://blogs.sun.com/sch/
