Open Stack

From: CARVER, PAUL [mailto:pc2929 at att.com]
Sent: Thursday, December 28, 2017 2:57 PM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [neutron][neutron-lib]Service function defintion files

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.
[Mooney, Sean K] as paul said above this has been a requirement for stadium membership for some time.
ocata was effectively the first release where this came in to effect https://github.com/openstack/neutron-specs/blob/master/specs/stadium/ocata.rst#how-reconcile-api-and-client-bindings
but it was started in newton https://github.com/openstack/neutron-specs/blob/master/specs/newton/neutron-stadium.rst with the concept of a neutron-api project which was folded into
neutron-lib when implemented instead of as an additional pure api project.




--
Paul Carver
V: 732.545.7377
C: 908.803.1656



-------- Original message --------
From: Ian Wells <ijw.ubuntu at cack.org.uk<mailto:ijw.ubuntu at cack.org.uk>>
Date: 12/27/17 21:57 (GMT-05:00)
To: OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [neutron][neutron-lib]Service function defintion files

Hey,

Can someone explain how the API definition files for several service plugins ended up in neutron-lib?  I can see that they've been moved there from the plugins themselves (e.g. networking-bgpvpn has https://github.com/openstack/neutron-lib/commit/3d3ab8009cf435d946e206849e85d4bc9d149474#diff-11482323575c6bd25b742c3b6ba2bf17<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_neutron-2Dlib_commit_3d3ab8009cf435d946e206849e85d4bc9d149474-23diff-2D11482323575c6bd25b742c3b6ba2bf17&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=HBNonG828PGilNRNwXAtdg&m=Ct8TKZR64-WFERXnsLkXWVRqR6D7hw31qKraVVIErz4&s=wPBSQzlYf76mAFHA9brzaY093kE7Vaek4pn8fFnjK7s&e=>) and that there's a stadium element to it judging by some earlier commits on the same directory, but I don't understand the reasoning why such service plugins wouldn't be self-contained - perhaps someone knows the history?

Thanks,
--
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180105/34c8a960/attachment.html>