On Thu, Jul 12, 2012 at 2:37 PM, George Reese <george.re...@enstratus.com>wrote:
> 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. > Perhaps my English is not the best, but what exactly is "constructive" about this? > > 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.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 > > > > > -- > 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
