Open Stack

I certainly wasn't picking on Vish, but instead the entire community so eagerly interested in option #1. You see, the OpenStack community has a perfect record of making sure stuff like that ends up breaking everyone between upgrades.

So, if you take offense by my comments… err, well, I'm not at all sorry. It's time for this community to grow the hell up and make sure systems upgrade nicely now and forever and that OpenStack environments are actually compatible with one another. Hell, I still find Essex environments that aren't even API compatible with one another. You have the Rackspace CTO wandering around conferences talking about how the value proposition of OpenStack is interoperability among clouds and yet you can't even get interoperability within the same OpenStack distribution of the same OpenStack version.

I smell a pile of bullshit and the community just keeps shoveling.

-George

On Jul 12, 2012, at 12:22 PM, Jay Pipes wrote:

> 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
>> 
> 
> 
> _______________________________________________
> 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

--
George Reese - Chief Technology Officer, enStratus
e: george.reese at enstratus.com    Skype: nspollution    t: @GeorgeReese    p: +1.207.956.0217
enStratus: Enterprise Cloud Management - @enStratus - http://www.enstratus.com
To schedule a meeting with me: http://tungle.me/GeorgeReese

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120712/a359493b/attachment.html>