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.wal...@rackspace.com> 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.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
