openstack team mailing list archive

[George Reese <george.reese@xxxxxxxxxxxxx>]

Being more offended by my choice of words than by the historic
compatibility and interoperability of OpenStack is a problem.

Sent from my iPhone

On Jul 12, 2012, at 18:19, Stefano Maffulli <stefano@xxxxxxxxxxxxx> wrote:

> George,
>
> your opinion is best conveyed if it comes with a polite choice of words.
> Please refrain from adding more of your references to excrements and
> help the community make a decision.
>
> /stef
>
>
> On 07/12/2012 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
>> <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
>>>>
>>>
>>
>>
>> _______________________________________________
>> 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