<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- <o:p></o:p></p>
<p class="MsoNormal">Paul Carver<o:p></o:p></p>
<p class="MsoNormal">VoIP: 732-545-7377<o:p></o:p></p>
<p class="MsoNormal">Cell: 908-803-1656<o:p></o:p></p>
<p class="MsoNormal">E: <a href="mailto:pcarver@att.com"><span style="color:#0563C1">pcarver@att.com</span></a><o:p></o:p></p>
<p class="MsoNormal"><a href="qto://talk/pc2929"><span style="color:#0563C1">Q Instant Message</span></a><o:p></o:p></p>
<p class="MsoNormal">It is difficult to make predictions. Especially about the future.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:2.25pt"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>From:</b> Ian Wells [mailto:ijw.ubuntu@cack.org.uk] <br>
<b>Sent:</b> Friday, December 29, 2017 14:00<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org><br>
<b>Subject:</b> Re: [openstack-dev] [neutron][neutron-lib]Service function defintion files<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">On 28 December 2017 at 06:57, CARVER, PAUL <<a href="mailto:pc2929@att.com" target="_blank">pc2929@att.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This is also a gating criteria for publishing API documentation on
<a href="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=" 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-- <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ian.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>