[openstack-dev] [TripleO] our update story: can people live with it?

Fox, Kevin M Kevin.Fox at pnnl.gov
Wed Jan 22 21:33:54 UTC 2014


Maybe I misunderstand, but I thought:

kexec - lets you boot a new kernel/initrd starting at the point a boot loader would skipping the bios init. All previous running processes are not running in the new boot just like a normal reboot.

CRIU - Lets you snapshot/restart running processes.

While you could use both together to upgrades kernel while leaving all the processes running after the reboot,  I don't think that's very tested at the moment. checkpointing the system memory is not without cost too. Restarting the services may be faster.

I think we're pretty far off in a tangent though. My main point was, if you can't selectively restart services as needed, I'm not sure how useful patching the image really is over a full reboot. It should take on the same order of magnitude service unavailability I think.

Thanks,
Kevin

________________________________________
From: Clint Byrum [clint at fewbar.com]
Sent: Wednesday, January 22, 2014 12:36 PM
To: openstack-dev
Subject: Re: [openstack-dev] [TripleO] our update story: can people live        with it?

Excerpts from Fox, Kevin M's message of 2014-01-22 12:19:56 -0800:
> I think most of the time taken to reboot is spent in bringing down/up the services though, so I'm not sure what it really buys you if you do it all. It may let you skip the crazy long bootup time on "enterprise" hardware, but that could be worked around with kexec on the full reboot method too.
>

If we could get kexec reliable.. but I have no evidence that it is
anything but a complete flake.

What it saves you is losing running processes that you don't end up
killing, which is expensive on many types of services.. Nova Compute
being a notable example.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list