On Fri, Apr 18, 2014 at 5:32 AM, Sean Dague <s...@dague.net> wrote: > On 04/18/2014 12:03 AM, Scott Devoid wrote: > > So I have had a chance to look over the whole review history again. I > > agree with Sean Dague and Dean Troyer's concerns that the current patch > > affects code outside of lib/storage and extras.d. We should make the > > Devstack extension system more flexible to allow for more extensions. > > Although I am not sure if this responsibility falls completely in the > > lap of those wishing to integrate Ceph. > > Where should it fall? This has been pretty common with trying to bring > in anything major, the general plumbing needs to come from that same > effort. It's also a pretty sane litmus test on whether this is a drive > by contribution that will get no support in the future (and thus just > expect Dean and I to go fix things), or something which will have > someone actively contributing to keep things working in the future. >
The issue is that it is very easy to suggest new features and refactoring when you are very familiar with the codebase. To a newcomer, though, you are basically asking me to do something that is impossible, so the logical interpretation is you're telling me to "go away". > > > What is more concerning though is the argument that /even when the Ceph > > patch meets these standards/ /it will still have to be pulled in from > > some external source. /Devstack is a central part of OpenStack's test > > and development system. Core projects depend upon it to develop and test > > drivers. As an operator, I use it to understand how changes might affect > > my production system. Documentation. Bug Triage. Outreach. Each of these > > tasks and efforts benefit from having a curated and maintained set > > extras in the mainline codebase. Particularly extras that are already > > represented by mainline drivers in other projects. > > My concern is that there is a lot of code in devstack. And every time I > play with a different set of options we don't enable in the gate, things > get brittle. For instance, Fedora support gets broken all the time, > because it's not tested in the gate. > > Something as big as using ceph for storage back end across a range of > services is big. And while there have been patches, I've yet to see > anyone volunteer 3rd party testing here to help us keep it working. Or > the long term commitment of being part of the devstack community > reviewing patches and fixing other bugs, so there is some confidence > that if people try to use this it works. > 100% agree. I was under the impression that integration of the ceph patches into devstack was a precursor to a 3rd party gate on ceph functionality. We have some VM resources to contribute to 3rd party tests, but I would need assistance in setting that up. > Some of the late reverts in nova for icehouse hit this same kind of > issue, where once certain rbd paths were lit in the code base within > 24hrs we had user reports coming back of things exploding. That makes me > feel like there are a lot of daemons lurking here, and if this is going > to be a devstack mode, and that people are going to use a lot, then it > needs to be something that's tested. > > If the user is pulling the devstack plugin from a 3rd party location, > then it's clear where the support needs to come from. If it's coming > from devstack, people are going to be private message pinging me on IRC > when it doesn't work (which happens all the time). > I see your motivations here. There are systems to help us with this though: redirect them to ask.openstack.org or bugs.launchpad.net and have them ping you with the link. Delegate replies to others. I try to answer any questions that pop up on #openstack but I need to look at the ask.openstack.org queue more often. Perhaps we need to put more focus on organizing community support and offloading that task from PTLs and core devs. > That being said, there are 2 devstack sessions available at design > summit. So proposing something around addressing the ceph situation > might be a good one. It's a big and interesting problem. > > -Sean > > -- > Sean Dague > Samsung Research America > s...@dague.net / sean.da...@samsung.com > http://dague.net > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
