Re: [vserver] start-vservers patch

From: Jeff Jansen <jeff.jansen_at_kkoncepts.net>
Date: Wed 02 Feb 2011 - 01:37:09 GMT
Message-ID: <4D48B545.7050504@kkoncepts.net>

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.

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 01:37:25 2011

[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 02 Feb 2011 - 01:37:25 GMT by hypermail 2.1.8