Quoth lianep at eng.sun.com on Fri, Jan 05, 2007 at 01:44:39PM -0800: > David Bustos writes: > > The service/instance split is for configuration sharing, but we haven't > > established definite guidelines for what should be shared when. I agree > > with you: since DNS is an open protocol, instances of > > "network/dns/server" should available to any implementation. But some > > members of our team feel that since we have already engineered > > dns/server to accommodate multiple instances of named, other > > implementations of DNS should use another service name, I guess. > > I'm the one that made the comment in the bug that the proposed solution > raised some concerns. dns/server instances should be available for > other implementations than ours. I've never claimed otherwise, so > please stop asserting that I have. > > However, I note that the only actual challenge in creating an instance > which describes an alternate implementation of dns/server is the bug in > svccfg import which causes properties to be stomped on.
I think there's more. Deliveries of alternate implementations can neutralize methods by overriding their exec strings as :true, but how should they nullify dependencies? As far as I can tell, they can only override the entities property to something else they already depend on. And those dependencies will show up in the user interface. This could be solved by allowing instances to have anti-property groups, which are planned for profiles, though not with this functionality (that is, an anti-property group on an instance would cover up the same property group on lower profiles, but not the same property group on a service). But even then, how can the alternative instance defend itself against future property groups which we might introduce? They can't. The solution is unmaintainable in the face of multiple implementations. > We *will* resolve the svccfg import bug. What's left is to decide > for dns/server: > > - are the implementation (of multiple instances of our dns/server) and > upgrade challenges which result from moving everything to the instance > surmountable? > > Probably, but it's ugly. That's what 6509773 should resolve. > Whether it's the right strategy depends on the time-frame for a > svccfg import fix plus a resolution to the next question. > > - Is moving everything to the instance for multi-instance > multi-implementation services the right long-term choice, or > is some sharing appropriate? > > Does the convenience of method and dependency sharing for the common case > (the dns/server we ship) justify forcing alternative implementations > to explicitly override the methods at the alternative implementation's > instance? > > We have 3 options here: > 1. Force everything to move to the instance for replacable services, > and require the admin AND service developer to deal with the hassle > of duplicating properties for shared configuration among the > instances. This solves today's bug, but is unpalatable as a long- > term strategy. > > 2. Specify that some service-level properties for the 'default' > OpenSolaris-delivered services are acceptable as long as they're > unlikely to hamper other alternate instances. Obviously, this > requires the svccfg import fix. This solution is less 'pure', > but is workable for most cases. It would involve leaving > dns/server as it is today. > > 3. Create a new mechanism so that configuration can be shared > 'across common instances'. Tricky, but worth considering as then > we could retain the purity of configuration separation while > allowing sharing among like instances. The new mechanism is > currently undefined as it would require a fair amount of considered > design. > > The reason I'd personally lean towards #2 for a medium-term approach > and #3 as a long-term one is that as long as manifest import doesn't > totally foul things up, people using the bundled software get a > benefit, yet we haven't locked out people who want to replace it > either. That's a good summary. I agree with option 3 in the long term, but I think option 2 is too risky in the medium term due to the aforementioned maintenance risks. Therefore I fall back to 1, unfortunate as it is. Now for the long term, I initially thought another level of hirearchy would be required. But as we're discussing, different implementations don't need to share properties, so perhaps this could be solved by mandating that services which are subject to alternative implmentations (i.e., open protocols) include an implementation designator in their service name, like "network/dns/server/bind". Then we could allow other services to depend on service prefixes, like "network/dns/server", which would automatically depend on the instacnes of dns/server/bind. Without a home for "network/dns/server" properties, though, single_instance semantics would be impossible to preserve. Fixing multiple-implementations would seem to be a good opportunity to allow daemons to implement multiple services, too. (Not that this is a big problem now, but it would ensure we were logically complete.) For that I think we would have to allow a service to specify which other services it implements. That could also be used to solve the above problem, but it may be awkward to expose in the user interface. David
