Open Stack

Excerpts from Doug Wiegley's message of 2016-07-19 13:58:59 -0600:
> 
> > On Jul 19, 2016, at 9:36 AM, Doug Hellmann <doug at doughellmann.com> wrote:
> > 
> > Excerpts from Hayes, Graham's message of 2016-07-18 17:13:09 +0000:
> >> On 18/07/2016 17:57, Thierry Carrez wrote:
> >>> Hayes, Graham wrote:
> >>>> [...]
> >>>> The point is that we were supposed to be a level field as a community
> >>>> but if we have examples like this, there is not a level playing field.
> >>> 
> >>> While I generally agree on your goals here (avoid special-casing some
> >>> projects in generic support projects like Tempest), I want to clarify
> >>> what we meant by "level playing field" in a recent resolution.
> >> 
> >> 
> >> Yes - it has been pointed out the title is probably overloading a term
> >> just used for a different purpose - I am more than willing to change it.
> >> 
> >> I wasn't sure where I got the name, and I realised that was probably in
> >> my head from that resolution.
> >> 
> >>> This was meant as a level playing field for contributors within a
> >>> project, not a level playing field between projects. The idea is that
> >>> any contributor joining any OpenStack project should not be technically
> >>> limited compared to other contributors on the same project. So, no
> >>> "secret sauce" that only a subset of developers on a project have access to.
> >> 
> >> There is a correlation here - "special sauce" (not secret obviously)
> >> that only a subset of projects have access to.
> >> 
> >>> I think I understand where you're gong when you say that all projects
> >>> should have equal chances, but keep in mind that (1) projects should not
> >>> really "compete" against each other (but rather all projects should
> >>> contribute to the success of OpenStack as a whole) and (2) some
> >>> OpenStack projects will always be more equal than others (for example we
> >>> require that every project integrates with Keystone, and I don't see
> >>> that changing).
> >> 
> >> Yes, I agree we should not be competing. But was should not be asking
> >> the smaller projects to re-implement functionality, just because they
> >> did not get integrated in time.
> >> 
> >> We require all projects to integrate with keystone for auth, as we
> >> require all projects to integrate with neutron for network operations
> >> and designate for DNS, I just see it as a requirement for using the
> >> other components of OpenStack for their defined purpose.
> >> 
> > 
> > It would be useful to have some specific information from the QA/Tempest
> > team (and any others with a similar situation) about whether the current
> > situation about how differences between in-tree tests and plugin tests
> > are allowed to use various APIs. For example, are there APIs only
> > available to in-tree tests that are going to stay that way? Or is this
> > just a matter of not having had time to "harden" or "certify" or
> > otherwise prepare those APIs for plugins to use them?
> 
> Doug, one example that I’m aware of — I’ve suggested moving neutron entirely out of devstack and into the neutron repo, via the devstack plugin interface. This was rejected, and the counter-argument given was that the folks that maintain the integrated gate, which happen to be many of the same folks maintaining devstack and the like, want to retain control of the items that can break the integrated gate, and that it gets too hard to track down individual project folks when the world is burning.
> 
> I don’t personally agree with the decision, but I can see some merit in that argument.

Yes, this is one of the outcomes of being in a situation where other
projects require something as a dependency -- each side loses a little
control, and some centralization happens to ensure that we can maintain
the flow of work for OpenStack as a whole.

Doug

> 
> Thanks,
> doug
> 
> > 
> > Doug
> > 
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>