Open Stack

On 28 December 2017 at 06:57, CARVER, PAUL <pc2929 at att.com> wrote:

> It was a gating criteria for stadium status. The idea was that the for a
> stadium project the neutron team would have review authority over the API
> but wouldn't necessarily review or be overly familiar with the
> implementation.
>
> A project that didn't have it's API definition in neutron-lib could do
> anything it wanted with its API and wouldn't be a neutron subproject
> because the neutron team wouldn't necessarily know anything at all about it.
>
> For a neutron subproject there would at least theoretically be members of
> the neutron team who are familiar with the API and who ensure some sort of
> consistency across APIs of all neutron subprojects.
>
> This is also a gating criteria for publishing API documentation on
> api.openstack.org vs publishing somewhere else. Again, the idea being
> that the neutron team would be able, at least in some sense, to "vouch for"
> the OpenStack networking APIs, but only for "official" neutron stadium
> subprojects.
>
> Projects that don't meet the stadium criteria, including having api-def in
> neutron-lib, are "anything goes" and not part of neutron because no one
> from the neutron team is assumed to know anything about them. They may work
> just fine, it's just that you can't assume that anyone from neutron has
> anything to do with them or even knows what they do.
>

OK - that makes logical sense, though it does seem that it would tie
specific versions of every service in that list to a common version of
neutron-lib as a byproduct, so it would be impossible to upgrade LBaaS
without also potentially having to upgrade bgpvpn, for instance.  I don't
know if that was the intention, but I wouldn't have expected it.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171229/905d5187/attachment.html>