openstack team mailing list archive

[Tim Bell <Tim.Bell@xxxxxxx>]

Vish,

How would the Nova migration from Essex to Folsom take place ? I'm wondering
how we can validate Folsom without risking an existing Essex installation
via some sort of clone/migrate operation.

What is your assessment of the risk that Cinder is less stable than Nova
volume ?

Option 1 would give no option if there are issues, we would have either to
stay on Essex entirely or wait until Folsom has the issues resolved.
However, option 1 would be much cleaner code wise.

Tim

> -----Original Message-----
> From: openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+tim.bell=cern.ch@xxxxxxxxxxxxxxxxxxx] On Behalf
> Of Vishvananda Ishaya
> Sent: 11 July 2012 17:27
> 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

Attachment: smime.p7s
Description: S/MIME cryptographic signature