David Bustos writes: > Quoth UNIX admin on Thu, Jan 04, 2007 at 03:40:41PM -0800:
> > Which means both Sun and I should implement refresh methods at > > instance levels, correct? If that's so, it's too bad we have to > > duplicate/double the work. > > Right. It depends on whether we want to accommodate non-BIND servers as > network/dns/server. My intuition says "we do", but some on our team > think otherwise. Keep an eye on 6509773, I suppose. You're inferring something from my comment in that bug that I neither stated nor implied. I specifically raised the issue that dns/server is designed to support multiple instances running simultaneously, for the implementation that we deliver in Solaris. That issue is a reason why a simple move of the dns/server properties (namely methods and a couple dependencies which are likely equivalent across all dns/server implementations) to the instance isn't an obviously correct solution to me at this point. If svccfg import didn't have the bug where multiple manifests defining the same service stomped all over each other, the situation would be far less severe and warrants more careful evaluation of the resolution. Specifically, I believe the dns/server example points to a conflict in potential use of service versus instances: (UNIX admin alludes to this as well) 1) Different instances may be used to describe different implementations of a service which equally satisfy the same dependency. e.g. the sendmail/postfix/etc. or syslogd/syslog-ng cases. Configuration (including method or dependency) sharing among instances is undesirable, as the implementations may be different. 2) Different instances may be used in cases where it is appropriate to have multiple copies of the same daemon running. This is the dns/server case as we deliver it today -- in this case, configuration sharing is appropriate and desirable. Methods, dependencies, and some parts of the configuration should be shared among instances and specified once, versus on every individual instance. This case gets complex when the potentially multi-instance service is commonly replaced/augmented with a different implementation. 3) Some combination of the above two where much of the implementation is shared, except for 'a little bit'. Blindly moving all configuration to the instance works around the current svccfg import bug, but at the expense of forcing configuration duplication that's hard to upgrade in cases like our current dns/server. It's particularly nasty to consider the scenario where someone's installed two different applications which implement dns/server, created instances for both of them, then the bundled dns/server implementation needs to change its methods. If we go with your proposed solution to 6509773, it's back to grotty shell scripting to determine which instances need to be upgraded. And even that may break. If, instead, svccfg import works in the face of multiple manifests with the same service, the common implementations of dns/server replacement would just work with the dns/server manifest we're shipping today -- the new delivered instance would just override the methods. I acknowledge that isn't necessarily architecturally pure. A better solution is desired. Templates and using templates for some sort of 'instance cloning' may be part of the answer (or may not), but mean that I'd like to make it through the templates implementation first before completely discarding the notion that we could address situations 2 and 3 above elegantly. liane -- Liane Praza, Solaris Kernel Development liane.praza at sun.com - http://blogs.sun.com/lianep
