Open Stack

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?

Mark.