Nicolas Williams writes: > So, representing some service configuration and running state in SMF is > extremely attractive because of dependency management, if nothing else.
True, but we were at that point discussing the configuration bits. > 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). That was part of the basis of my question: will temporary instances _ever_ appear in SMF, or are they just a Bad Idea in general? Mike's answer, if I understand it correctly, was not just that there's another way to do this (single instance, multiple properties), but that this way supports temporaries just fine, and doesn't require SMF changes. I can actually go either way, but if I go the way you're suggesting then I really *do* need to know whether the SMF community thinks that temporary instances are viable and somewhere on the extended road map for the system. If they're not, then I really can't see my way clear to creating a nasty little kludge that ends up living forever. At least not on purpose. Thus my original question. > > 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). It also clearly allows us to replace the backend parameter storage. > 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. Yep; agreed. In the case of Spanning Tree, the configuration bits are pretty darned simple and fit well in SMF. The complexity here is in dealing with the ubiquitous "-t" option. If temporary things (other than just "enable") aren't a good idea, then perhaps we ought to start stamping down on them -- sooner rather than later -- because we're busily growing those options all over the place. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
