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