On Sun, May 18, 2014 at 11:27 AM, John Griffith <john.griff...@solidfire.com > wrote:
> > > > On Sun, May 18, 2014 at 9:54 AM, Mike Perez <thin...@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@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
