<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 December 2017 at 11:00, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 28 December 2017 at 06:57, CARVER, PAUL <span dir="ltr"><<a href="mailto:pc2929@att.com" target="_blank">pc2929@att.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This is also a gating criteria for publishing API documentation on <a href="http://api.openstack.org" target="_blank">api.openstack.org</a> 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.</div>
<div><br>
</div>
<div>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.</div></div></blockquote><div><br></div></span><div>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.</div></div></div></div></blockquote><div><br></div><div>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.  </div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div>-- </div><div>Ian.</div></font></span></div></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>