Mailing List Archive

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.


>> 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...


> 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.


> If the description above matches
> the code modifications, then there should be three instead of
> one patch.
>

Fair enough - I was being lazy!


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

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: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/