2014-04-18 12:32 GMT+02:00 Sean Dague <s...@dague.net>: > 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.
As far as litmus tests go, this is a very biased one. If someone has the skill, time, and inclination to undertake whatever refactoring is needed to add their bit of functionality, yes, that's an indication that they'd be able to maintain it long term. Whether they'll have the time and/or inclination to actually do so is anybody's guess. I think it's an unnecessarily high bar to set for every contributor. We happily accept patches that don't require major refactoring or plumbing changes regardless of whether or not the contributor would have had the skill, time or inclination to do those things as well, simply because this contributor's changes didn't happen to require such efforts. Conversely, just because someone has the skill, time, and inclination to add a small, simple features and actively maintain it forever and ever, doesn't mean they have the skill, time or inclination to undertake a major refactoring. I'm not saying it's your job to do it all instead, but if a contributor provides a patch that is useful and is proven to work (devstack runs are easily reproducable) and it doesn't break anything else (ensured by the gate), it seems like some amount of work should fall on the core team to make sure things move forward either by: a) accepting the patch as is and tending to the refactoring later on, b) doing the refactoring straight away and getting the contributor to adjust their code accordingly, or c) providing enough guidance for the contributor to be able to do the refactoring. > 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. How can we gate on it, if devstack doesn't support it? If we (the OpenStack project) or someone else actually cares about Fedora support, we/they should be running the tests. If noone cares enough to test it, let it be broken. If it's dragging anything else down with it somehow, rip it out. But, if devstack doesn't support it, how do we expect people to run these tests? > 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. There's obviously a chicken-and-egg situation there. Sure, we could repeat the exact test runs done in OpenStack and report back whether they worked for us. However, that's unlikely to actually be useful to OpenStack (repeating the same test with the same configuration in a very similar environment isn't likely to be very informative). Also, it's almost entirely useless to us, because our real environment will be running with a different configuration, so we're not actually getting much additional confidence in the changes coming in from upstream by running the 3rd party tests. Only once the toolchain allows us to run tests with a configuration that actually vaguely mimics our real environment will we (or OpenStack for that matter) have anything to gain from having us run 3rd party tests. > 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. This sounds completely backwards to me. Devstack is how things are deployed in OpenStack's gates. I'd expect people wanting to provide 3rd party testing back to OpenStack to try to use the same tools to do so, i.e. devstack. Devstack is supposed (at least as I undertand it) to exactly be the tool to let us test things in a reproducable fashion, but it seems to me that you're saying that things need to already be covered by other methods of testing before it can get into devstack? Had devstack had support for Ceph, someone could have much more easily been running these tests in an automated, continuous fashion and have raised these issues at a more appropriate time. > 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). Is your suggestion for people to maintain forks of devstack for things like this? That's certainly a solution, but not what I'd have expected. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev