Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
On Sun, May 18, 2014 at 11:27 AM, John Griffith wrote: > > > > On Sun, May 18, 2014 at 9:54 AM, Mike Perez 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
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
On Sun, May 18, 2014 at 9:54 AM, Mike Perez 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
Thanks for your reply and advice. Manual update of the database can achieve it, however, I don't think it is reasonable especially in a production environment. 2014-05-14 23:43 GMT+08:00 Vishvananda Ishaya : > > On May 14, 2014, at 12:14 AM, Zhangleiqiang (Trump) < > zhangleiqi...@huawei.com> 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. > > While the above use case may be common, you are explicitly changing the > config of the system, and requiring a manual update of the database in this > case seems reasonable to me. > > Vish > > > > > Thanks. > > > > -- > > zhangleiqiang (Trump) > > > > Best Regards > > > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- --- Best Regards Trump.Zhang ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder] Question about storage backend capacity expansion
On May 14, 2014, at 12:14 AM, 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. While the above use case may be common, you are explicitly changing the config of the system, and requiring a manual update of the database in this case seems reasonable to me. Vish > > Thanks. > > -- > zhangleiqiang (Trump) > > Best Regards > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Cinder] Question about storage backend capacity expansion
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. -- zhangleiqiang (Trump) Best Regards ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
