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. It sounds like you're doing it wrong. Why don't you fail-over on a guest-by-guest basis? > 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 -- Daniel Hokka Zakrisson