I think it sort of was intentional, although probably not the primary focus. I don’t remember if it is a stadium requirement or merely a suggestion, but I believe it is strongly encouraged that “official” stadium sub-projects should follow neutron’s release cycle whereas “unofficial” projects are free to do whatever they want with regard to release cycle, just like with regard to API.
The definition of “stadium” is in some sense tautological. The main benefit of being in the stadium is that you tell someone you’re in the stadium they automatically know that there’s a set of assumptions that they can make about the project. The requirement for being in the stadium is that you do the necessary work to make those assumptions valid. If the developers don’t care whether people can validly make those assumptions, there’s no pressure on them to be in the stadium. If the users don’t care about those assumptions, there’s no reason why they should prefer stadium projects over non-stadium projects. It’s essentially just a label that declares that a specific set of requirements have been met. It’s up to each individual to evaluate whether they care about that specific set of requirements. -- Paul Carver VoIP: 732-545-7377 Cell: 908-803-1656 E: pcar...@att.com<mailto:pcar...@att.com> Q Instant Message<qto://talk/pc2929> It is difficult to make predictions. Especially about the future. From: Ian Wells [mailto:ijw.ubu...@cack.org.uk] Sent: Friday, December 29, 2017 14:00 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][neutron-lib]Service function defintion files On 28 December 2017 at 06:57, CARVER, PAUL <pc2...@att.com<mailto: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<https://urldefense.proofpoint.com/v2/url?u=http-3A__api.openstack.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=HBNonG828PGilNRNwXAtdg&m=GqHaQCoy3Tvyg8H0NL9cSBDP_CC89OcfRNL28Q9AZcI&s=Fsy6AOROmR5biRFONfOt4pP30zz-pz44mnTdHv_hkxc&e=> 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
