Subject: Re: [vserver] start-vservers patch
From: Oliver Heinz <oheinz@fbihome.de>
Date: Wed, 2 Feb 2011 11:52:14 +0100

 Wed, 2 Feb 2011 11:52:14 +0100

I think all of that can be handled well by cluster management software like 
pacemaker [1]. With it's score system  you may define priorities with group, 
order and colocation constraints you can define dependencies. But it is a 
rather complex job to configure such a setup - and it's a rather complex piece 
of software that is needed to handle that. I think an init-Script is not 
exactly the right place to handle cluster failover scenarios.

just my 0,02€

Oliver

[1] http://clusterlabs.org/wiki/Main Page



Am Mittwoch, 2. Februar 2011, um 06:21:25 schrieb Herbert Poetzl:
> 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