Open Stack

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 at lists.launchpad.net
>> <mailto:openstack at lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> --
> George Reese - Chief Technology Officer, enStratus
> e: george.reese at enstratus.com <mailto:george.reese at enstratus.com>   
> 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>