Open Stack

On Sun, May 18, 2014 at 9:54 AM, Mike Perez <thingee at gmail.com> wrote:

> On 07:14 Wed 14 May     , Zhangleiqiang (Trump) wrote:
> > Hi, all:
> >       I meet a requirement in my OpenStack environment which initially
> uses one LVMISCSI backend. Along with the usage, the storage is
> insufficient, so I want to add a NFS backend to the exists Cinder.
> >
> >       There is only a single Cinder-volume in environment, so I need to
> configure the Cinder to use "multi-backend", which means the initial
> LVMISCSI storage and the new added NFS storage are both used as the
> backend. However, the existing volume on initial LVMISCSI backend will not
> be handled normally after using multi-backend, because the "host" of the
> exists volume will be thought down.
> >
> >       I know that the "migrate" and "retype" APIs aim to handle the
> "backend capacity expansion", however, each of them can't used for this
> situation.
> >
> >       I think the use case above is common in production environment. Is
> there some existing method can achieve it ? Currently, I manually updated
> the "host" value of the existing volumes in database, and the existing
> volumes can then be handled normally.
> >
> >       Thanks.
>
> This is exactly what migrate is suppose to help with. Unfortunately as you
> mentioned, it's not available in the LVM or NFS driver.
>
> --
> Mike Perez
>
> ​As Vish pointed out this is a config change really, so the DB change is
kind of an expected thing.  That being said, I've run into this before and
I'm thinking of proposing a change in Juno that allows the ability to
modify config from single to multiple backends without "losing" access to
the original volume host that we had setup in the table.

Migrate doesn't really help with this anyway, you're not actually
"migrating" anything.  You're taking what you had on a configured system
and just breaking the ability to control it by changing the host-name
associated with it.  I believe this is going to be a good use case for
manage/unmanage [1] but it's not going to preserve some things which could
be a problem in your case.

[1] https://review.openstack.org/#/c/72501


 _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140518/79273043/attachment.html>