On 28 December 2017 at 06:57, CARVER, PAUL <pc2...@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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev