On Fri, Jan 05, 2007 at 01:44:39PM -0800, lianep at eng.sun.com wrote:
> 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?
Note that these questions are relevant to many other services where
customers may want to create additional instances, either of the same
Sun-provided service software or of third-party software.
E.g.,
- ntp (e.g., OpenNTPD)
- ssh (e.g., additional instances on separate ports, with different
configuration, possibly using OpenSSH instead of SUNWssh, or
some other implementation)
- http
Etcetera.
A standard method for creating additional instances cloned from :default
would be nice.
A way to create manifests for alternate instances that doesn't stomp on
general properties or other instances' properties would be nice, but
you're already working on that.
> 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?
For stop and refresh methods a default :kill method should often
suffice. So I say ship those and let 3rd parties override them where
:kill is not appropriate.
> 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'd say #2 where feasible, else #1. I'm not sure that you can share
anything more than trivial :kill methods across disparate
implementations of the same sort of service without forcing all those
implementors to support a common set of SMF properties, and I can see
some open source projects balking at that.
Nico
--
