On Fri, Mar 07, 2008 at 01:04:01PM -0500, James Carlson wrote: > Joost Mulders writes: > > I have no opinion about temporary instances, but I do have another > > concern about this statement: > > > > > This means storing the configuration data in SMF ... > > > > When SMF was introduced I remember the general feedback from customers > > being "great as long as it doesn't become a big giant registry blob". > > I fully agree with that. > > I have great sympathy with that. I've been using UNIX and Unix-like > systems for around 25 years, and flat files have a number of > attractive properties that ODM and the MSFT "Registry" do not. > > However, that ship has sailed. It went with Greenline (PSARC > 2002/547).
And even if not much configuration information is stored in SMF a la registry, there's still the fact that SMF can represent dependencies, and if you have a server that needs to have a dependency on a particular bridge, network profile, whatever, well, if you can't rely on SMF to provide that dependency checking for you then you have to build an alternative. So, representing some service configuration and running state in SMF is extremely attractive because of dependency management, if nothing else. In this case I think the best thing to do is to use instances and leave the turds on reboot disabled (perhaps a service to delete what-should- have-been-temporary-instances would help, and we can get rid of it later when temporary interfaces appear). > I had thought that the reason we treat all new configuration files > (/etc/dladm/*) as Private was that they're just a temporary expediency > until they can be redesigned into SMF. Is that not the case? Hmmm, I thought it's because we need to provide *adm(1M) CLIs for managing configuration because that's much better than $EDITOR (for many reasons, including making it easier for us to evolve the relevant interfaces). When application configuration is sufficiently simple it can live in SMF as service properties that can be administered via svccfg(1M). For more complicated things the config info might still reside in SMF, but be administered via a new adm command, or it might not reside in SMF at all. Nico --
