[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-API] [PATCH] add pool join and eject hooks executing /etc/xapi.d/pool-{join, eject}/*

On Wed, 2010-05-05 at 16:23 +0100, Dave Scott wrote:
> Hi Ian,
> > I placed the hooks at the end of each action. I didn't go as far as
> > {pre,post}x{join,eject} but could do if that is desirable.
> Perhaps we should name the hooks pool_post_{join,eject} just to leave space 
> for adding the "pre" ones later?

Sounds sensible.

> [...]
> I think we should run the pool_eject_hook as the last thing before the
> finally (fun () -> light_fuse_and_reboot_after_eject()) since the
> light_fuse_* functions start an async background thread with a timer
> in it. We run the risk of the script hook not quite completing in time
> before the host reboots.

I didn't know about the async, moving it before seems very sensible.

or perhaps I should add the hook to the end of the async background
thread, just before the reboot?

> It's also worth double-checking that a script containing CLI commands
> actually works when run at this point -- this is well after a bunch of
> important files are deleted, such as the pool secret. If this doesn't
> work then I recommend switching over to pool_post_join and
> pool_pre_eject :-)

My use case doesn't actually need to do any XenAPI/CLI stuff (it needs
to notify the vswitch that we have changed pool). Is a hook which has
the explicit caveat "no XenAPI access" acceptable?


xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.