openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #14532
Re: [nova] [cinder] Nova-volume vs. Cinder in Folsom
On 07/12/2012 12:32 PM, George Reese wrote:
> This community just doesn't give a rat's ass about compatibility, does it?
a) Please don't be inappropriate on the mailing list
b) Vish sent the email below to the mailing list *precisely because* he
cares about compatibility. He wants to discuss the options with the
community and come up with a reasonable action plan with the Cinder PTL,
John Griffith for the move
Now, would you care to be constructive with your criticism?
Thanks,
-jay
> On Jul 11, 2012, at 10:26 AM, Vishvananda Ishaya 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
>
> --
> George Reese - Chief Technology Officer, enStratus
> e: george.reese@xxxxxxxxxxxxx <mailto:george.reese@xxxxxxxxxxxxx>
> Skype: nspollution t: @GeorgeReese p: +1.207.956.0217
> enStratus: Enterprise Cloud Management - @enStratus
> - http://www.enstratus.com <http://www.enstratus.com/>
> To schedule a meeting with me: http://tungle.me/GeorgeReese
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
Follow ups
References