Open Stack

On Fri, Apr 18, 2014 at 5:32 AM, Sean Dague <sean at 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
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/29fb844c/attachment.html>