openstack team mailing list archive

[Matt Joyce <matt.joyce@xxxxxxxxxxxxxxxx>]

To certain extent I agree with george's sentiment.

Recent example... we're changing tenants  to projects in the keystone api.

Yes we maintain v2 api compatibility but there will be a cost to users in
the confusion of decisions like this.  George is right to be calling for
openstack to grow up.

That's my personal opinion.

-Matt


On Thu, Jul 12, 2012 at 11:55 AM, George Reese
<george.reese@xxxxxxxxxxxxx>wrote:

> 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@xxxxxxxxxxxxxxxxxxx
>
> <mailto:openstack@xxxxxxxxxxxxxxxxxxx <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<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
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>  --
> George Reese - Chief Technology Officer, enStratus
> e: george.reese@xxxxxxxxxxxxx    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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>