Open Stack

On Sun, May 18, 2014 at 11:27 AM, John Griffith <john.griffith at solidfire.com
> wrote:

>
>
>
> 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
>>
>
>
​FYI, I've filed a bug for this including what the current options are (add
a cinder node, or modify the database).

https://bugs.launchpad.net/cinder/+bug/1320688​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140518/b3edd59f/attachment.html>