Open Stack

On Wed, Aug 13, 2014 at 5:13 AM, Mark McLoughlin <markmc at redhat.com> wrote:

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


I'll bite, but please note this is a strawman.

No:
* Accepting any more projects into incubation until we are comfortable with
the state of things again
* Marconi
* Ceilometer

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.
* Sahara
* Trove
* Tripleo


Yes:
* All integrated projects that are not listed above



>
> Mark.
>
>
> _______________________________________________
> 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/20140813/5e284f9c/attachment.html>