<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 13, 2014 at 5:13 AM, Mark McLoughlin <span dir="ltr"><<a href="mailto:markmc@redhat.com" target="_blank">markmc@redhat.com</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 Thu, 2014-08-07 at 09:30 -0400, Sean Dague wrote:<br>
<br>
> While I definitely think re-balancing our quality responsibilities back<br>
> into the projects will provide an overall better release, I think it's<br>
> going to take a long time before it lightens our load to the point where<br>
> we get more breathing room again.<br>
<br>
</div>I'd love to hear more about this re-balancing idea. It sounds like we<br>
have some concrete ideas here and we're saying they're not relevant to<br>
this thread because they won't be an immediate solution?<br>
<div class=""><br>
> This isn't just QA issues, it's a coordination issue on overall<br>
> consistency across projects. Something that worked fine at 5 integrated<br>
> projects, got strained at 9, and I think is completely untenable at 15.<br>
<br>
</div>I can certainly relate to that from experience with Oslo.<br>
<br>
But if you take a concrete example - as more new projects emerge, it<br>
became harder to get them all using oslo.messaging and using it<br>
consistent ways. That's become a lot better with Doug's idea of Oslo<br>
project delegates.<br>
<br>
But if we had not added those projects to the release, the only reason<br>
that the problem would be more manageable is that the use of<br>
oslo.messaging would effectively become a requirement for integration.<br>
So, projects requesting integration have to take cross-project<br>
responsibilities more seriously for fear their application would be<br>
denied.<br>
<br>
That's a very sad conclusion. Our only tool for encouraging people to<br>
take this cross-project issue is being accepted into the release and,<br>
once achieved, the cross-project responsibilities aren't taken so<br>
seriously?<br>
<br>
I don't think it's so bleak as that - given the proper support,<br>
direction and tracking I think we're seeing in Oslo how projects will<br>
play their part in getting to cross-project consistency.<br>
<div class=""><br>
> I think one of the big issues with a large number of projects is that<br>
> implications of implementation of one project impact others, but people<br>
> don't always realize. Locally correct decisions for each project may not<br>
> be globally correct for OpenStack. The GBP discussion, the Rally<br>
> discussion, all are flavors of this.<br>
<br>
</div>I think we need two things here - good examples of how these<br>
cross-project initiatives can succeed so people can learn from them, and<br>
for the initiatives themselves to be patiently lead by those whose goal<br>
is a cross-project solution.<br>
<br>
It's hard work, absolutely no doubt. The point again, though, is that it<br>
is possible to do this type of work in such a way that once a small<br>
number of projects adopt the approach, most of the others will follow<br>
quite naturally.<br>
<br>
If I was trying to get a consistent cross-project approach in a<br>
particular area, the least of my concerns would be whether Ironic,<br>
Marconi, Barbican or Designate would be willing to fall in line behind a<br>
cross-project consensus.<br>
<div class=""><br>
> People are frustrated in infra load, for instance. It's probably worth<br>
> noting that the 'config' repo currently has more commits landed than any<br>
> other project in OpenStack besides 'nova' in this release. It has 30%<br>
> the core team size as Nova (<a href="http://stackalytics.com/?metric=commits" target="_blank">http://stackalytics.com/?metric=commits</a>).<br>
<br>
</div>Yes, infra is an extremely busy project. I'm not sure I'd compare<br>
infra/config commits to Nova commits in order to illustrate that,<br>
though.<br>
<br>
Infra is a massive endeavor, it's as critical a part of the project as<br>
any project in the integrated release, and like other "strategic<br>
efforts" struggles to attract contributors from as diverse a number of<br>
companies as the integrated projects.<br>
<div class=""><br>
> So I do think we need to really think about what *must* be in OpenStack<br>
> for it to be successful, and ensure that story is well thought out, and<br>
> that the pieces which provide those features in OpenStack are clearly<br>
> best of breed, so they are deployed in all OpenStack deployments, and<br>
> can be counted on by users of OpenStack.<br>
<br>
</div>I do think we try hard to think this through, but no doubt we need to do<br>
better. Is this conversation concrete enough to really move our thinking<br>
along sufficiently, though?<br>
<div class=""><br>
> Because if every version of<br>
> OpenStack deploys with a different Auth API (an example that's current<br>
> but going away), we can't grow an ecosystem of tools around it.<br>
<br>
</div>There's a nice concrete example, but it's going away? What's the best<br>
current example to talk through?<br>
<div class=""><br>
> This is organic definition of OpenStack through feedback with operators<br>
> and developers on what's minimum needed and currently working well<br>
> enough that people are happy to maintain it. And make that solid.<br>
><br>
> Having a TC that is independently selected separate from the PTLs allows<br>
> that group to try to make some holistic calls here.<br>
><br>
> At the end of the day, that's probably going to mean saying No to more<br>
> things. Everytime I turn around everyone wants the TC to say No to<br>
> things, just not to their particular thing. :) Which is human nature.<br>
> But I think if we don't start saying No to more things we're going to<br>
> end up with a pile of mud that no one is happy with.<br>
<br>
</div>That we're being so abstract about all of this is frustrating. I get<br>
that no-one wants to start a flamewar, but can someone be concrete about<br>
what they feel we should say 'no' to but are likely to say 'yes' to?<br></blockquote><div><br></div><div><br></div><div>I'll bite, but please note this is a strawman.</div><div><br></div><div>No:</div>
<div>* Accepting any more projects into incubation until we are comfortable with the state of things again</div><div>* Marconi</div><div>* Ceilometer</div><div><br></div><div>Divert all cross project efforts from the following projects so we can focus our cross project resources. Once we are in a bitter place we can expand our cross project resources to cover these again. This doesn't mean removing anything.</div>
<div>* Sahara<br></div><div>* Trove</div><div>* Tripleo</div><div><br></div><div><br></div><div>Yes:<br>* All integrated projects that are not listed above</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Mark.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br></div></div>