openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

The stated and agreed-upon goal from Essex forward is to make the core OpenStack projects N+1 compatible (e.g. Essex->Folsom, Folsom->Grizzly), and to make the clients capable of talking to every API version forever.

Anything standing in the way of that should be considered a release-blocking bug, and should be filed against the appropriate projects. I for one intend to see to that as best I can.

That said, there *is* a grey area around "migration" steps like Nova Volume -> Cinder. If the migration path is clear, stable, well-documented, uses the same schemas and same APIs... I'd say that *may* still fall into the category of N+1 compatible. It sounds like that's the idea here, but that we need to thoroughly vet the practicality of that assertion. I don't think we can decide this without proof that the clean transition is 100% possible.

Code isn't the only thing of value; constructively and respectfully shaping design decisions is great, testing and filing bugs is also fantastic. Profanity and disrespect are not acceptable. Ever.

All the best,


-          Gabriel

From: openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of George Reese
Sent: Thursday, July 12, 2012 12:15 PM
To: Brian Waldon
Cc: Openstack (openstack@xxxxxxxxxxxxxxxxxxx) (openstack@xxxxxxxxxxxxxxxxxxx)
Subject: Re: [Openstack] [nova] [cinder] Nova-volume vs. Cinder in Folsom

So if Im not coding, I should shut up?

I think you answered your own question.

Sent from my iPhone

On Jul 12, 2012, at 14:10, Brian Waldon <brian.waldon@xxxxxxxxxxxxx<mailto:brian.waldon@xxxxxxxxxxxxx>> wrote:
What exactly was so offensive about what I said? Communities like OpenStack are built on top of people *doing* things, not *talking* about things. I'm just asking you to contribute code or design help rather than slanderous commentary.

Brian " "Offensive" " Waldon

On Jul 12, 2012, at 11:59 AM, George Reese wrote:


You evidently have not had to live with the interoperability nightmare known as OpenStack in the same way I have. Otherwise, you would find responses like Brian's much more offensive.

-George

On Jul 12, 2012, at 1:48 PM, Christopher B Ferris wrote:


This level of response is unnecessary.

That said, the perspectives which influenced the decision seemed somewhat weighted to the development community. I could be wrong, but I did not see much input from the operations community as to the impact.

Clearly, going forward, we want to be more deliberate about changes that may have impact on operations and he broader ecosystem that bases its efforts on assumptions established at the start of a release cycle, rather than on changes introduced late in the cycle.

Cheers

Chris

Sent from my iPad

On Jul 12, 2012, at 2:24 PM, "George Reese" <george.reese@xxxxxxxxxxxxx<mailto:george.reese@xxxxxxxxxxxxx>> wrote:
Well, I think overall OpenStack has done an absolute shit job of compatibility and I had hoped (and made a huge point of this at the OpenStack conference) Diablo -> Essex would be the end of this compatibility bullshit.

But the attitudes in this thread and with respect to the whole Cinder question in general suggest to me that this cavalier attitude towards forward migration hasn't changed.

So you can kiss my ass.

-George

On Jul 12, 2012, at 12:11 PM, Brian Waldon wrote:


We actually care a hell of a lot about compatibility. We also recognize there are times when we have to sacrifice compatibility so we can move forward at a reasonable pace.

If you think we are handling anything the wrong way, we would love to hear your suggestions. If you just want to make comments like this, I would suggest you keep them to yourself.

Have a great day!
Brian Waldon

On Jul 12, 2012, at 9:32 AM, George Reese wrote:


This community just doesn't give a rat's ass about compatibility, does it?

-George

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