<div dir="ltr">Hey Sean :)<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 2, 2014 at 4:15 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br></div><snip><br>
<br>
The immune response is there for a reason.<br></blockquote><div><br></div><div>Agreed. There is good reason. And big downside risk to the project. The cost of it is a suppression of contributions from people that aren't incentivised to go the extra mile, operators being a prime example. </div>
<div><br></div><div>Tactically, I'm not sure that I think that functionally gating on deployment capability in devstack, which is billed as opinionated is the best idea though. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

At the same time I understand that people do want these things. So how<br>
do we find a way to keep the upstream code something that's maintained<br>
and working for people. Plenty of Fedora folks complain devstack is<br>
always broken on Fedora, and it is, because nothing automatically checks<br>
that code.<br>
<div><div class="h5"><br>
> Case in point. In the absence of a budget, unit testing is better than<br>
> not, but integration testing ends up being more important in my<br>
> experience. The thing that trumps both of them is real experience in<br>
> actual large scale systems.<br>
<br>
</div></div>I agree, with a caveat. The real experience captures the state of<br>
working today. Which is great. It doesn't, however, help us keep things<br>
working tomorrow.<br>
<br>
There are, currently, 391 patches up for review in Nova, right now. Any<br>
of those are capable of breaking OpenStack for everyone. Human eyes are<br>
good, but completely foulable. Human eyes + integration tests are much<br>
better.</blockquote><div><br></div><div>That is fair.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

We should *definitely* also figure out how to get more large sale<br>
experience injected back in. I think it's clear Summit is not that<br>
venue, so the next question is where might that venue exist, if it's a<br>
physical place, or a virtual one. The Linux Foundation addressed this<br>
sort of issue around Linux with the End Users Summit as a completely<br>
different kind of gathering event mostly to bridge these divides.<br>
<br>
But maybe a real world event doesn't work well here. What about some<br>
better format to get operator stories back into the hands of the<br>
development community. I'd love nothing more than a regular voice/video<br>
presentation by various operators discussing their installations and<br>
major pain points, in a level of detail where we could start to figure<br>
out parts / pieces that can be tackled in the near term (current cycle).<br></blockquote><div><br></div><div>I'm a bit jaded about user stories; I'm not sure it is possible extract the right information without more of a discussion sort of format. </div>
<div><br></div><div>Lorin Hochstein had a great idea a while ago. He proposed a shadowing program, where devs spend time with ops folks in person:</div><div><a href="http://lorinhochstein.wordpress.com/2013/11/30/adopt-an-op/">http://lorinhochstein.wordpress.com/2013/11/30/adopt-an-op/</a></div>
<div><br></div><div>Through this discussion, I've started to appreciate the depth of the (social) scalability challenges you guys are facing. It is pretty likely that we're hitting amdahl's law one way or another here. What do you think the limiting factor is?<br>
</div><div><br></div><div>People keep bringing up the linux kernel "mainline isn't for users" approach. I think that one of the sticking points for us is that there isn't any appropriate downstream integration point. We run the ubuntu releases that we patch at our site. But I wouldn't consider trying to get code integrated through that path. The reasonable limit for distros is probably filing bugs, and probably only for bugs as opposed to feature requests or patches, particularly if you aren't a paying customer.</div>
<div><br></div><div>This has actually a long term issue. We started running the anso packages, back in the day, and have had this difficult process of picking which bits to run for a long time. I wonder if it would help to have some set of releases that are intended for users, with some ability (and effort allocated from the project side) to triage issues more closely, or maybe work operator relevant patches through the system. It might be worth a shot to try building some activities explicitly with hybrid goals.</div>
<div> -nld</div></div></div></div>