On Wed, Feb 02, 2011 at 09:37:09AM +0800, Jeff Jansen wrote:
> On Tuesday 01,February,2011 09:30 PM, Daniel Hokka Zakrisson wrote:
> > I still fail to see why you care what order they start in. If you don't
> > have explicit dependencies between them, i.e. you don't use depends, then
> > why does it matter? If you just set the number of parallel starts to
> > whatever number you want, that is the number that will be running at once,
> > all the time.
> Because some vservers are more "important" than others. When a primary
> host node crashes and a secondary takes over, I want the important
> vservers to start up before the less important ones.
> When I do a kernel upgrade on the hosts and switch the primary and
> secondary, I want the "important" vservers to shutdown last on one side
> and startup first on the other. Then they are down for just a few
> seconds. "Unimportant" vservers shutdown first and startup last. They
> may be down for a couple of minutes.
> It's not that the machines "depend" on each other; it's that some are
> much more "mission-critical" than others. I want the mail servers to
> come back first, for example. Vservers running testing or development
> environments, however, should be started last.
> I don't want to leave this to alphabetical order by the config
> directory, which is what you get now. I want to say that vserver 'C'
> should start first, vserver 'F' next, and so on. No matter how many I
> start in parallel and no matter how long it takes for any individual
> machine to start, they will come up in this order.
> Obviously this isn't a felt need for your situation. Many people
> probably agree with you. When I asked about this on the list (over a
> year ago) only a few folks answered, and those who did said that they
> had worked out their own methods for starting vservers in a certain
> order. I'm proposing a way to 'standardize' this so it doesn't have to
> be "worked out" again.
I think Daniel might be more inclined to add such a feature
if it would handle the strict order you want to introduce
as a priority instead ...
i.e. let's assume each guest has a 'priority' entry, which
classifies the guest within an arbitrarily high numeric
range (like 0 - MAX_INT), and which is consulted when the
dependancies and the parallel startup have a bunch of other-
wise equal guests to select from
putting numbers like 100, 200, 300, ... in that priority
entry would then be able to prefer one guest over the other
despite the fact that 10 guests are always started at once
or none of them have any dependancy ...
HTH,
Herbert
> But of course, if only a handful of folks actually need this, then it's
> a waste of time and an unnecessary complication to include it. Those of
> us who need it will continue to use our own methods.
> Jeff Jansen
Received on Wed Feb 2 05:21:35 2011