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