Hi Avery,
> The simple approach to obtaining this behavior would be to write a
> definition for each instance. This provides a very fine control over what
> is and isn't running but the maintenance of it is increasingly prohibitive
> with each instance added. For larger installations, I don't see this as
> practical to maintain.
If you have a fixed number of instance, it's not significantly harder.
The main problem if is you have a dynamic number of instances. Changing the
main service tree dynamically is probably abusing the framework, and some
additional tool is probably needed here.
> A possible solution would be to create a separate svscan directory, use the
> same script for each instance with separate per-instance settings, and
> start all of the instances as a process sub-tree of the parent svscan.
Yes.
As soon as you think of using a supervision tree to do that kind of thing,
more glue work is needed. Creating a specialised subtree sounds like a good
idea, because it gives you separate places to 1. factor all the commonalities
and 2. instantiate.
There are more advantages to this than you give it credit for. For instance,
you can run all your subtree under a dedicated user, with dedicated quota. You
can factor more than the run script - most of the configuration can be done
at the "master" level.
However, yes, dynamically creating, configuring and removing instances is
still heavy maintenance; but is certainly possible to automate a large
part of the grunt work.
> Is there a better way to accomplish this, or a common consensus about how
> to handle this situation? Or do people simply deal with the pain of
> writing all of the instances as they are needed?
So far, I'm not aware of any consensus. Dynamic instantiation isn't something
lots of thoughts have been given about yet; thanks for bringing it to our
attention.
What kind of utilities would you need to make it easier to manage and maintain
dynamic instantiation ?
--
Laurent
Received on Sat Nov 29 2014 - 12:01:33 UTC