Open Stack

On 08/13/2014 08:41 PM, Joe Gordon wrote:
> 
> 
> 
> On Wed, Aug 13, 2014 at 5:13 AM, Mark McLoughlin <markmc at redhat.com
> <mailto: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

I won't -1 but I  won't +1 this either. In order to establish this list,
we need to go through the "must have" requirements and see how many of
them are met by these projects and whether there are good established
plans to meet the ones left, if any.

Speaking for Zaqar (Marconi), we've been always honest about the project
maturity and a good example of this is the withdrawal of our last
graduation request. However, it wouldn't be fair to just leave out some
projects - Ceilometer or even Zaqar - because our community and
requirements keep shifting very fast. I don't mean to say that projects
shouldn't keep up with the community changes but I do think we should
also go through the projects history and give value to future plans when
some of the *new* requirements are not met.

I'd be curious to know what made you think about Ceilometer and Zaqar as
"No" projects. This information would help moving the discussion forward
and obviously it'd help both projects to improve.

Flavio

-- 
@flaper87
Flavio Percoco