Open Stack

On Mon, Sep 29, 2014 at 11:58 AM, Doug Hellmann <doug at doughellmann.com>
wrote:

>
> On Sep 29, 2014, at 5:51 AM, Thierry Carrez <thierry at openstack.org> wrote:
>
> > Boris Pavlovic wrote:
> >> it goes without saying that working on cross-project stuff in OpenStack
> >> is quite hard task.
> >>
> >> Because it's always hard to align something between a lot of people from
> >> different project. And when topic start being too "HOT"  the discussion
> >> goes in wrong direction and attempt to do cross project change fails, as
> >> a result maybe not *ideal* but *good enough* change in OpenStack will be
> >> abandoned.
> >>
> >> The another issue that we have are "specs". Projects are asking to make
> >> spec for change in their project, and in case of cross project stuff you
> >> need to make N similar specs (for every project). That is really hard to
> >> manage, and as a result you have N different specs that are describing
> >> the similar stuff.
> >>
> >> To make this process more formal, clear and simple, let's reuse process
> >> of "specs" but do it in one repo /openstack/cross-project-specs.
> >>
> >> It means that every cross project topic: Unification of python clients,
> >> Unification of logging, profiling, debugging api, bunch of others will
> >> be discussed in one single place..
> >
> > I think it's a good idea, as long as we truly limit it to cross-project
> > specs, that is, to concepts that may apply to every project. The
> > examples you mention are good ones. As a counterexample, if we have to
> > sketch a plan to solve communication between Nova and Neutron, I don't
> > think it would belong to that repository (it should live in whatever
> > project would have the most work to do).
> >
> >> Process description of cross-project-specs:
> >>
> >>  * PTL - person that mange core team members list and puts workflow +1
> >>    on accepted specs
> >>  * Every project have 1 core position (stackforge projects are included)
> >>  * Cores are chosen by project team, they task is to advocate project
> >>    team opinion
> >>  * No more veto, and -2 votes
> >>  * If > 75% cores +1 spec it's accepted. It means that all project have
> >>    to accept this change.
> >>  * Accepted specs gret high priority blueprints in all projects
> >
> > So I'm not sure you can force "all projects to accept the change".
> > Ideally, projects should see the benefits of alignment and adopt the
> > common spec. In our recent discussions we are also going towards more
> > freedom to projects, rather than less : imposing common specs to
> > stackforge projects sounds like a step backwards there.
> >
> > Finally, I see some overlap with Oslo, which generally ends up
> > implementing most of the "common policy" into libraries it encourages
> > usage of. Therefore I'm not sure having a "cross-project" PTL makes
> > sense, as he would be stuck between the Oslo PTL and the Technical
> > Committee.
>
> There is some overlap with Oslo, and we would want to be involved in the
> discussions — especially if the plan includes any code to land in an Oslo
> library. I have so far been resisting the idea that oslo-specs is the best
> home for this, mostly because I didn’t want us to assume everything related
> to cross-project work is also related to Oslo work.
>
> That said, our approval process looks for consensus among all of the
> participants on the review, in addition to Oslo cores, so we can use
> oslo-specs and continue incorporating the +1/-1 votes from everyone. One of
> the key challenges we’ve had is signaling buy-in for cross-project work so
> having some sort of broader review process would be good, especially to
> help ensure that all interested parties have a chance to participate in the
> review.
>
> OTOH, a special repo with different voting permission settings also makes
> sense. I don’t have any good suggestions for who would decide when the
> voting on a proposal had reached consensus, or what to do if no consensus
> emerges. Having the TC manage that seems logical, but impractical. Maybe a
> person designated by the TC would oversee it?
>

Here is a governance patch to propose a openstack-specs repo:
https://review.openstack.org/125509


>
> >
> >> With such simple rules we will simplify cross project work:
> >>
> >> 1) Fair rules for all projects, as every project has 1 core that has 1
> >> vote.
> >
> > A "project" is hardly a metric for fairness. Some projects are 50 times
> > bigger than others. What is a "project" in your mind ? A code repository
> > ? Or more like a program (a collection of code repositories being worked
> > on by the same team ?)
> >
> > So in summary, yes we need a place to discuss truly cross-project specs,
> > but I think it can't force decisions to all projects (especially
> > stackforge ones), and it can live within a larger-scope Oslo effort
> > and/or the Technical Committee.
> >
> > --
> > Thierry Carrez (ttx)
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> 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/20141001/67c99b68/attachment.html>