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