<div dir="ltr"><div><div><div><div><div><div>There are precedents for this. For example, the attributes that currently exist for IPv6 advertisement are very similar:<br><br></div>- added during the run of a stable Neutron API<br></div>- properties added on a Neutron object (MTU and VLAN affect network, but IPv6 affects subnet - same principle though)<br></div><div>- settable, but with defaults so they're optional<br></div>- turn up in output when the subnet information is fetched<br><br></div>With the one caveat (write your code to ignore properties you don't understand) this seems to address backward compatibility in both the IPv6 and the MTU/VLAN attribute changes - if you completely ignore the attribute behaviour is enough the way it used to be that your app won't break.<br><br>Now, it may be that no-one noticed the ipv6 changes as they went through, but given the long debate about what the attributes should look like at the time they did get reasonable attention. Do we want to change the rules for future API changes?<br></div>-- <br></div>Ian.<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 March 2015 at 10:07, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif">
<div>Hi,</div>
<div>Until now all changes to the API’s have been made in separate extensions and not in the base. These should actually be on the provider networks extension.</div>
<div>First this code is not supported by any of the plugins other than the ML2 (I am not sure if this break things – it certain broke the unit tests). Secondly these two changes do not have open source reference implementations (but that is digressing from
the problem).</div>
<div>I really think that we need to revert these and have the extensions done in the standard fasion.</div>
<div>Thanks</div>
<div>Gary</div>
<div><br>
</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span>Brandon Logan <<a href="mailto:brandon.logan@RACKSPACE.COM" target="_blank">brandon.logan@RACKSPACE.COM</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, March 19, 2015 at 6:20 PM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron] Neutron extenstions<br>
</div><div><div class="h5">
<div><br>
</div>
<div>
<div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Isn't this argument as to whether those fields should be turned off/on, versus just always being on? Are there any guidelines as to what fields are allowed to be added in that base resource attr map? If ML2 needs these and other fields, should they just
always be on?<br>
</p>
<p><br>
</p>
<p>Thanks,<br>
</p>
<p>Brandon<br>
</p>
<div style="word-wrap:break-word">
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font style="font-size:11pt" face="Calibri,sans-serif" color="#000000"><b>From:</b> Doug Wiegley <<a href="mailto:dougwig@parksidesoftware.com" target="_blank">dougwig@parksidesoftware.com</a>><br>
<b>Sent:</b> Thursday, March 19, 2015 11:01 AM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Neutron] Neutron extenstions</font>
<div> </div>
</div>
<div>
<div>Hi Gary,</div>
<div><br>
</div>
First I’m seeing these, but I don’t see that they’re required on input, unless I’m mis-reading those reviews. Additional of new output fields to a json object, or adding optional inputs, is not generally considered to be backwards incompatible behavior in
an API. Does OpenStack have a stricter standard on that?
<div><br>
</div>
<div>Thanks,</div>
<div>doug<br>
<div><br>
</div>
<div><br>
<div>
<div>
<blockquote type="cite">
<div>On Mar 19, 2015, at 6:37 AM, Gary Kotton <<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>> wrote:</div>
<br>
<div>
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">
<div>Hi,</div>
<div>Changed the subject so that it may draw a little attention.</div>
<div>There were 2 patches approved that kind of break the API (in my humble opinion):</div>
<div><a href="https://review.openstack.org/#/c/154921" target="_blank">https://review.openstack.org/#/c/154921</a>/ and <a href="https://review.openstack.org/#/c/158420" target="_blank">https://review.openstack.org/#/c/158420</a>/ </div>
<div>In both of these two new fields were added to the base attributes – mtu and vlan_transparency</div>
<div>Reverts for them are:</div>
<div><a href="https://review.openstack.org/165801" target="_blank">https://review.openstack.org/165801</a> (mtu) and <a href="https://review.openstack.org/165776" target="_blank">https://review.openstack.org/165776</a> (vlan transparency).</div>
<div>In my opinion these should be added as separate extensions.</div>
<div>Thanks</div>
<div>Gary</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span>Gary Kotton <<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, March 19, 2015 at 2:32 PM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Neutron] VLAN transparency support<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">
<div>Hi,</div>
<div>This patch has the same addition too - <a href="https://review.openstack.org/#/c/154921" target="_blank">https://review.openstack.org/#/c/154921</a>/. We should also revert that one.</div>
<div>Thanks</div>
<div>Gary</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span>Gary Kotton <<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, March 19, 2015 at 1:14 PM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [Neutron] VLAN transparency support<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap:break-word;font-size:14px;font-family:Calibri,sans-serif">
<div>Hi,</div>
<div>It appears that <a href="https://review.openstack.org/#/c/158420" target="_blank">https://review.openstack.org/#/c/158420</a>/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others.</div>
<div>I do not think that this is the correct way to go and we should do this as all other extensions have been maintained. I have posted a revert (<a href="https://review.openstack.org/#/c/165776" target="_blank">https://review.openstack.org/#/c/165776</a>/)
– please feel free to knack if it is invalid.</div>
<div>Thanks</div>
<div>Gary</div>
</div>
</div>
</span></div>
</div>
</span></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div></span>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>