← Back to team overview

openstack team mailing list archive

Re: [nova] [cinder] Nova-volume vs. Cinder in Folsom

 

It would be great if anyone who is already deploying Openstack, even if in non-production environments, could give cinder a try.
For a test environment, it seems easy enough to make the switch using devstack (I have verified this with XenServer, and I believe, John and folks at Rackspace have tried on KVM).
Of course, only when more people start trying it will we get a realistic picture.

Thanks,
Renuka.

From: Flavia Missi [mailto:flaviamissi@xxxxxxxxx]
Sent: Wednesday, July 11, 2012 12:56 PM
To: Renuka Apte
Cc: Vishvananda Ishaya; Openstack (openstack@xxxxxxxxxxxxxxxxxxx) (openstack@xxxxxxxxxxxxxxxxxxx)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

For me it's +1 to 1, but...

Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just "forces" us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to "fear" the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing...

Anyway... :)

Thanks,
On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte <renuka.apte@xxxxxxxxxx<mailto:renuka.apte@xxxxxxxxxx>> wrote:
+1 for 1

On 11/07/12 8:26 AM, "Vishvananda Ishaya" <vishvananda@xxxxxxxxx<mailto:vishvananda@xxxxxxxxx>> wrote:

>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<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



--
Flavia


Follow ups

References