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