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.re...@enstratus.com> 
> 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@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
>>> 
>> 
>> --
>> 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

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

Reply via email to