Hi, On Thu, Mar 21, 2013 at 02:59:17PM +0000, Tim Small wrote: > On 13/03/13 16:18, Dejan Muhamedagic wrote: > > On Tue, Mar 12, 2013 at 12:58:44PM +0000, Tim Small wrote: > > > >> The attached patch changes the behaviour of the OpenVZ virtual machine > >> cluster resource agent, so that: > >> > >> 1. The default resource stop timeout is greater than the hardcoded > >> > > Just for the record: where is this hardcoded actually? Is it > > also documented? > > > > Defined here: > > http://git.openvz.org/?p=vzctl;a=blob;f=include/env.h#l26 > > /** Shutdown timeout. > */ > #define MAX_SHTD_TM 120 > > > > Used by env_stop() here: > > http://git.openvz.org/?p=vzctl;a=blob;f=src/lib/env.c#l821 > <http://git.openvz.org/?p=vzctl;a=blob;f=src/lib/env.c;h=2da848d87904d9e572b7da5c0e7dc5d93217ae5b;hb=HEAD#l818> > > > > for (i = 0; i < MAX_SHTD_TM; i++) { > sleep(1); > if (!vps_is_run(h, veid)) { > ret = 0; > goto out; > } > } > > kill_vps: > logger(0, 0, "Killing container ..."); > > > > Perhaps something based on wall time would be more consistent, and I can > think of cases where users might want it to be a bit higher, or a bit > lower, but currently it's just fixed at 120s. > > > I can't find the timeout documented anywhere.
That makes it hard to reference in other software products. But we can anyway increase the advised timeout in the metadata. > >> 2. The start operation now waits for resource startup to complete i.e. > >> for the VE to "boot up" (so that the cluster manager can detect VEs > >> which are hanging on startup, and also throttle simultaneous startups, > >> so as not-to overburden the node in question). Since the start > >> operation now does a lot more, the default start operation timeout has > >> been increased. > >> > > I'm not sure if we can introduce this just like that. It changes > > significantly the agent's behaviour. > > > > Yes. I think it probably makes the agent's behavour a bit more correct, > but that depends what your definition of a VE resource having "started" > is, I suppose. Currently with this agent the says that it has started > as soon as it has begun the boot process, whereas with the proposed > change, it would mean that it has started when it has booted up (which > should imply "is operational"). > > Although my personal reason for the change was so that I had a > reasonable way to avoid booting tens of VEs on the host machine at the > same time, I can think of other benefits - such as making other > resources depend on the fully-booted VE, or detecting the case where a > faulty VE host node causes the VE to hang during start-up. > > > I suppose other options are: > > 1. Make start --wait the default, but make starting without waiting > selectable using a RA parameter. > > 2. Make start without waiting the default, but make --wait selectable > using a RA parameter. > > > I suppose that the change will break configurations where the > administrator has hard coded a short timeout, and this change is > introduced as part of an upgrade, which I suppose is a bad thing... Yes, it could be so. I think that we should go for option 2. > > BTW, how does vzctl know when the VE is started? > > > > The vzctl manual page says that 'vzctl start --wait' will "attempt to > wait till the default runlevel is reached" within the container. OK. Though that may mean different things depending on which init system is running. > > If the description above matches > > the code modifications, then there should be three instead of > > one patch. > > > > Fair enough - I was being lazy! :) Cheers, Dejan > > Tim. > > -- > South East Open Source Solutions Limited > Registered in England and Wales with company number 06134732. > Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ > VAT number: 900 6633 53 http://seoss.co.uk/ +44-(0)1273-808309 > > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
