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.
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.
I'm not tied to that choice, but am trying to encourage consideration of
the tradeoffs of each solution on *all* use cases -- not just
the use case where dns/server is replaced. I'm trying to talk about
tradeoffs between the solutions, and each solution proposed is intended
to accomodate a bundled named, an un-bundled named, and a posited
completely different implementation.
liane
--
Liane Praza, Solaris Kernel Development
liane.praza at sun.com - http://blogs.sun.com/lianep
