openstack team mailing list archive

[George Reese <george.reese@xxxxxxxxxxxxx>]

This ain't the first time I've had a run in with you where your response was essentially "if you don't like it, go code it".

And obviously you missed the entire "constructive" point in my response. It's this:

The proposed options suck. It's too late to do anything about that as this ship has sailed.

What you need to understand going forward is that this community has an abysmal history when it comes to compatibility and interoperability.

Abysmal.

Not checkered. Not patchy. Not "lacking". Abysmal.

Horizontally. Vertically. Abysmal.

Actually, shockingly abysmal.

You saw one public response laughing at me for expecting this community to care about compatibility. I also received private responses with the same sentiment.

If you guys really think you care about compatibility, you need to go sit in a corner and do some heavy thinking. Because the history of this project and this thread in particular suggest otherwise.

In case you missed it again, here it is in a single sentence: 

The constructive point I am making is that it's time to wake up and get serious about compatibility and interoperability.

-George

On Jul 12, 2012, at 2:27 PM, Brian Waldon wrote:

> Planning the development of the projects is valuable as well as contributing code. If you review my last message, you'll see the words '... or design help', which I intended to represent non-code contribution. You seem to have strong opinions on how things should be done, but I don't see your voice in any of the community discussions.
> 
> Moving forward, I wish you would share your expertise in a constructive manner. Keep in mind this list reaches 2200 people. Let's not waste anyone's time.
> 
> WALDON
> 
> 
> On Jul 12, 2012, at 12:14 PM, George Reese wrote:
> 
>> 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> 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> 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
>>>>>>>>> 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
>>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 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
>>>> 
>>>> --
>>>> 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
>>>> 
>>> 
> 

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