Open Stack

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.

> 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.

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).

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
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/635fce30/attachment.pgp>