[openstack-dev] [nova][cinder] About rebuilding volume-backed instances.

Clint Byrum clint at fewbar.com
Wed Nov 11 07:21:34 UTC 2015


Excerpts from Zhenyu Zheng's message of 2015-11-09 00:21:23 -0800:
> Hi,
> 
> Thanks for the reply, for some scenario, launching an new instance is
> easier. But for production deployment, an instance may contain a large
> number of data such as keypairs, metadata, bdm etc. and it may have
> multiple internet interfaces that are connected to multiple networks. That
> is to say, for operations like recovery, change/update operating system, to
> build an new instance is a lot more "expensive" than rebuild it. And one
> instance may have some volumes that are marked as delete_on_terminate =
> True, if that is the situation, build an new instance will not save the
> user data in user volume, but rebuild can protect them.
> 
> So, I think this is a quite reasonable demand for OpenStack.
>

I completely respect the fact that you have real users and they are
asking for this. I am sure you're doing what you can to convince them to
build cloud-ready applications.

Unfortunately, you're trying to work around misuse of the cloud API's,
not missing features from them. Don't use those volume types, and don't
build systems that rely on single ports and interfaces. IMO rebuild is a
misguided concept (something that took me a long time to realize). It
requires one service (Nova) to take all of the responsibility for
cross-service reinitialization and that doesn't happen so you get weird
disconnects like this one. Heat would be a better choice, as you can
simply deploy a new template, which will replace the old instance in
a relatively safe way including detaching and re-attaching volumes and
any VIP's.

So, to be clear:

*DO* build systems that store data on volumes that are _not_ the root
disk. Boot a new instance, initialize the configuration using your
tools, and then move the volume attachment from the old to the new.

*DO* build systems that use DNS or a VIP to communicate so that new
ports can be allocated and attached to the new instance while the old
one is stil active.

> On Mon, Nov 9, 2015 at 3:28 PM, Clint Byrum <clint at fewbar.com> wrote:
> 
> > Excerpts from Zhenyu Zheng's message of 2015-11-08 23:04:59 -0800:
> > > Hi All,
> > >
> > > Currently, we have strong demands about "rebuilding"(or actions like
> > > rebuilding) volume-backed instances. As in production deployment, volume
> > > backed instance is widely used. Users have the demands of performing the
> > > rebuild(recovery) action for root device while maintain instance UUID
> > sorts
> > > of information, many users also wants to keep the volume uuid unchanged.
> > >
> > > Nova side doesn't support using Rebuild API directly for volume backed
> > > instances (the volume will not change). And Nova side also doesn't
> > support
> > > detaching root device, that means we cannot performing volume
> > > backup/restore from cinder side, because those actions needs the volume
> > in
> > > "available" status.
> > >
> > > Now there are couple of patches proposed in nova trying to fix this
> > problem:
> > > [1] https://review.openstack.org/#/c/201458/
> > > [2] https://review.openstack.org/#/c/221732/
> > > [3] https://review.openstack.org/#/c/223887/
> > >
> > > [1] and [2] are trying to expose the API of detaching root devices, [3]
> > is
> > > trying to fix it in the current Rebuild API. But yet none of them got
> > much
> > > attention.
> > >
> > > As we now have strong demand on performing the "rebuilding" action for
> > > volume-backed instances, and yet there is not any clear information about
> > >  it. I wonder is there any plans of how to support it in Nova and Cinder?
> > >
> >
> > This seems entirely misguided by the users.
> >
> > Why not just boot a new instance on a new volume with the same image?
> > Names can be the same.. UUID's should never be anything except a physical
> > handle.
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >



More information about the OpenStack-dev mailing list