On 2008-12-04T17:20:43, Florian Haas <[EMAIL PROTECTED]> wrote:
> > The resource must be fully operational after start (or migrate_from)
> > have completed. Monitor must immediately be OK.
>
> What?
>
> If I'm not mistaken, the purpose of an external monitor_script in
> conjunction with a virtual domain would be to do something like ping it,
> try to connect to its TCP port 22, connect to its TCP port 445 (for a
> virtual Windows box), etc. Any such monitor script only has a chance to
> succeed when the virtual domain is fully booted. The start operation
> from the VirtualDomain RA (just like that from the Xen RA) returns
> immediately after the virtualization management API has determined that
> the virtual domain has successfully _started_ its boot process, not
> completed it.
>
> What would be your suggestion to determine, from Pacemaker's
> perspective, that a virtual domain is fully booted?
It's not pacemaker's job to determine that. The RA must wait and not
return until this state has been reached.
The ordering dependencies are one extremly good reason, but monitor ops
could also occur "out of the blue" if the user invokes a reprobe
manually or something.
The easiest way is to loop in start until monitor succeeded, if there is
any doubt that the start action has been achieved.
> > while ! monitor_function ; do sleep 1 ; done
> So what is your suggestion?
Uhm, I think the above line is actually valid shell code ;-)
> 1. Augment the monitor operation with any external monitor_script and
> block any start or migrate_from until monitor succeeds? In that case,
> please educate me as to the purpose of monitor timeouts. Or are you
> saying one would have to adjust start and migrate_from timeouts accordingly?
Well, sure. start/migrate_from must cover the full time until the
resource has reached the requested state. Returning earlier is not
allowed, or rather, possibly will cause subtle errors somewhere.
Also consider the UI impact. The GUI would show the resource as "green"
and no longer in transition; still the admin would get a connection
refused; not good.
start means "start the resource and return when it is started, or some
error has occured." It does not mean "trigger the start and return".
Sorry for being pedantic, but its quite important to get the semantics
right - they are not very complicated, but observing them really makes
the cluster more dependable.
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
