Open Stack

On 29 December 2017 at 11:00, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> 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.
>

It was intentional and was meant to help stabilize/sync up the core (of
neutron) with the subprojects. Without it it would be practically
impossible for a downstream consumer to figure out what works with which.
As a side effect, the lack of well thought out API versioning in Neutron
means we can't quite introduce breaking changes in the API and that means
we'll probably never bump the neutron-lib's major version.


> --
> Ian.
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171229/fdbc297c/attachment.html>