Open Stack

2014-04-18 12:32 GMT+02:00 Sean Dague <sean at 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/