<br><tt><font size=2>+1 to option 1, rip the band-aid off quickly  :-)</font></tt>
<br>
<br><tt><font size=2>-Doug</font></tt>
<br>
<br><tt><font size=2>> -----Original Message-----<br>
> From: openstack-bounces+gregory_althaus=dell.com@lists.launchpad.net<br>
> [mailto:openstack-bounces+gregory_althaus=dell.com@lists.launchpad.<br>
> net] On Behalf Of Vishvananda Ishaya<br>
> Sent: Wednesday, July 11, 2012 10:27 AM<br>
> To: Openstack (openstack@lists.launchpad.net) (openstack@lists.launchpad.net)<br>
> Subject: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom<br>
> <br>
> Hello Everyone,<br>
> <br>
> Now that the PPB has decided to promote Cinder to core for the <br>
> Folsom release, we need to decide what happens to the existing Nova
<br>
> Volume code. As far as I can see it there are two basic strategies.
<br>
> I'm going to give an overview of each here:<br>
> <br>
> Option 1 -- Remove Nova Volume<br>
> ==============================<br>
> <br>
> Process<br>
> -------<br>
>  * Remove all nova-volume code from the nova project<br>
>  * Leave the existing nova-volume database upgrades and tables
in<br>
>    place for Folsom to allow for migration<br>
>  * Provide a simple script in cinder to copy data from the nova<br>
>    database to the cinder database (The schema for the tables
in<br>
>    cinder are equivalent to the current nova tables)<br>
>  * Work with package maintainers to provide a package based upgrade<br>
>    from nova-volume packages to cinder packages<br>
>  * Remove the db tables immediately after Folsom<br>
> <br>
> Disadvantages<br>
> -------------<br>
>  * Forces deployments to go through the process of migrating
to cinder<br>
>    if they want to use volumes in the Folsom release<br>
> <br>
> Option 2 -- Deprecate Nova Volume<br>
> =================================<br>
> <br>
> Process<br>
> -------<br>
>  * Mark the nova-volume code deprecated but leave it in the project<br>
>    for the folsom release<br>
>  * Provide a migration path at folsom<br>
>  * Backport bugfixes to nova-volume throughout the G-cycle<br>
>  * Provide a second migration path at G<br>
>  * Package maintainers can decide when to migrate to cinder<br>
> <br>
> Disadvantages<br>
> -------------<br>
>  * Extra maintenance effort<br>
>  * More confusion about storage in openstack<br>
>  * More complicated upgrade paths need to be supported<br>
> <br>
> Personally I think Option 1 is a much more manageable strategy <br>
> because the volume code doesn't get a whole lot of attention. I want<br>
> to keep things simple and clean with one deployment strategy. My <br>
> opinion is that if we choose option 2 we will be sacrificing <br>
> significant feature development in G in order to continue to <br>
> maintain nova-volume for another release.<br>
> <br>
> But we really need to know if this is going to cause major pain to
<br>
> existing deployments out there. If it causes a bad experience for
<br>
> deployers we need to take our medicine and go with option 2. Keep
in<br>
> mind that it shouldn't make any difference to end users whether <br>
> cinder or nova-volume is being used. The current nova-client can use<br>
> either one.<br>
> <br>
> Vish<br>
> <br>
> <br>
> _______________________________________________<br>
> Mailing list: https://launchpad.net/~openstack<br>
> Post to     : openstack@lists.launchpad.net<br>
> Unsubscribe : https://launchpad.net/~openstack<br>
> More help   : https://help.launchpad.net/ListHelp<br>
</font></tt>