<div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 18, 2014 at 9:54 AM, Mike Perez <span dir="ltr"><<a href="mailto:thingee@gmail.com" target="_blank">thingee@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 07:14 Wed 14 May , Zhangleiqiang (Trump) wrote:<br>
> Hi, all:<br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks.<br>
<br>
</div>This is exactly what migrate is suppose to help with. Unfortunately as you<br>
mentioned, it's not available in the LVM or NFS driver.<br>
<span class=""><font color="#888888"><br>
--<br>
Mike Perez<br>
</font></span><div class=""><div class="h5"><br></div></div></blockquote><div class="gmail_default" style="font-family:'courier new',monospace">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. </div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style><font face="courier new, monospace">[1] <a href="https://review.openstack.org/#/c/72501">https://review.openstack.org/#/c/72501</a></font><br>
</div><div class="gmail_default" style><font face="courier new, monospace"><br></font></div><div class="gmail_default" style><font face="courier new, monospace"><br></font></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>