<div dir="ltr">In order to track this, and for Kyle's sanity, I have created these two RC1 bugs:<div><br></div><div>- <a href="https://bugs.launchpad.net/neutron/+bug/1434667">https://bugs.launchpad.net/neutron/+bug/1434667</a><br></div><div>- <a href="https://bugs.launchpad.net/neutron/+bug/1434671">https://bugs.launchpad.net/neutron/+bug/1434671</a><br></div><div><br></div><div>Please, let's make sure that whatever approach we decide on, the resulting code fix targets those two bugs.</div><div><br></div><div>Thanks,</div><div>Armando</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 March 2015 at 09:51, Armando M. <span dir="ltr"><<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 19 March 2015 at 23:59, Akihiro Motoki <span dir="ltr"><<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forwarding my reply to the other thread too...<br>
<br>
Multiple threads on the same topic is confusing.<br>
Can we use this thread if we continue the discussion?<br>
(The title of this thread looks approapriate)<br>
<br>
----<br>
API extension is the only way that users know which features are<br>
available unitl we support API microversioning (v2.1 or something).<br>
I believe VLAN transparency support should be implemented as an<br>
extension, not by changing the core resources attribute directly.<br>
Otherwise users (including Horizon) cannot know we field is available or not.<br>
<br>
Even though VLAN transparency and MTU suppotrs are basic features, it<br>
is better to be implemented as an extension.<br>
Configuration does not help from API perspective as it is not visible<br>
through the API.<br></blockquote><div><br></div></span><div>I was only suggesting the configuration-based approach because it was simpler and it didn't lead to the evil mixin business. Granted it does not help from the API perspective, but we can hardly claim good discoverability of the API capabilities anyway :)</div><div><br></div><div>That said, I'd be ok with moving one or both of these attributes to the extension framework. I thought that consensus on having them as core resources had been reached at the time the spec proposal.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We are discussing moving away from extension attributes as Armando commented,<br>
but I think it is discussed about resources/attributes which are<br>
already used well and required.<br>
It looks natural to me that new resources/attributes are implemented<br>
via an extension.<br>
The situation may be changed once we have support of API microversioning.<br>
(It is being discussed in the context of Nova API microvesioning in<br>
the dev list started by Jay Pipes.)<br>
<br>
In my understanding, the case of IPv6 two mode is an exception.<br>
>From the initial design we would like to have fully support of IPv6 in<br>
subnet resource,<br>
but through the discussion of IPv6 support it turns out some more<br>
modes are required,<br>
and we decided to change the subnet "core" resource. It is the exception.<br>
<br>
Thanks,<br>
Akihiro<br>
<div><div><br>
2015-03-20 8:23 GMT+09:00 Armando M. <<a href="mailto:armamig@gmail.com" target="_blank">armamig@gmail.com</a>>:<br>
> Forwarding my reply to the other thread here:<br>
><br>
> ~~~~<br>
><br>
> If my memory does not fail me, changes to the API (new resources, new<br>
> resource attributes or new operations allowed to resources) have always been<br>
> done according to these criteria:<br>
><br>
> an opt-in approach: this means we know the expected behavior of the plugin<br>
> as someone has coded the plugin in such a way that the API change is<br>
> supported;<br>
> an opt-out approach: if the API change does not require explicit backend<br>
> support, and hence can be deemed supported by all plugins.<br>
> a 'core' extension (ones available in neutron/extensions) should be<br>
> implemented at least by the reference implementation;<br>
><br>
> Now, there might have been examples in the past where criteria were not met,<br>
> but these should be seen as exceptions rather than the rule, and as such,<br>
> fixed as defects so that an attribute/resource/operation that is<br>
> accidentally exposed to a plugin will either be honored as expected or an<br>
> appropriate failure is propagated to the user. Bottom line, the server must<br>
> avoid to fail silently, because failing silently is bad for the user.<br>
><br>
> Now both features [1] and [2] violated the opt-in criterion above: they<br>
> introduced resources attributes in the core models, forcing an undetermined<br>
> behavior on plugins.<br>
><br>
> I think that keeping [3,4] as is can lead to a poor user experience; IMO<br>
> it's unacceptable to let a user specify the attribute, and see that<br>
> ultimately the plugin does not support it. I'd be fine if this was an<br>
> accident, but doing this by design is a bit evil. So, I'd suggest the<br>
> following, in order to keep the features in Kilo:<br>
><br>
> Patches [3, 4] did introduce config flags to control the plugin behavior,<br>
> but it looks like they were not applied correctly; for instance, the<br>
> vlan_transparent case was only applied to ML2. Similarly the MTU config flag<br>
> was not processed server side to ensure that plugins that do not support<br>
> advertisement do not fail silently. This needs to be rectified.<br>
> As for VLAN transparency, we'd need to implement work item 5 (of 6) of spec<br>
> [2], as this extension without at least a backend able to let tagged traffic<br>
> pass doesn't seem right.<br>
> Ensure we sort out the API tests so that we know how the features behave.<br>
><br>
> Now granted that controlling the API via config flags is not the best<br>
> solution, as this was always handled through the extension mechanism, but<br>
> since we've been talking about moving away from extension attributes with<br>
> [5], it does sound like a reasonable stop-gap solution.<br>
><br>
> Thoughts?<br>
> Armando<br>
><br>
> [1]<br>
> <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html" target="_blank">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html</a><br>
> [2]<br>
> <a href="http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html" target="_blank">http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html</a><br>
> [3]<br>
> <a href="https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z" target="_blank">https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z</a><br>
> [4]<br>
> <a href="https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z" target="_blank">https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z</a><br>
> [5] <a href="https://review.openstack.org/#/c/136760/" target="_blank">https://review.openstack.org/#/c/136760/</a><br>
><br>
> On 19 March 2015 at 14:56, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>> wrote:<br>
>><br>
>> On 19 March 2015 at 11:44, Gary Kotton <<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>> Just the fact that we did this does not make it right. But I guess that<br>
>>> we<br>
>>> are starting to bend the rules. I think that we really need to be far<br>
>>> more<br>
>>> diligent about this kind of stuff. Having said that we decided the<br>
>>> following on IRC:<br>
>>> 1. Mtu will be left in the core (all plugins should be aware of this and<br>
>>> treat it if necessary)<br>
>>> 2. Vlan-transparency will be moved to an extension. Pritesh is working on<br>
>>> this.<br>
>><br>
>><br>
>> The spec started out as an extension, and in its public review people<br>
>> requested that it not be an extension and that it should instead be core.  I<br>
>> accept that we can change our minds, but I believe there should be a good<br>
>> reason for doing so.  You haven't given that reason here and you haven't<br>
>> even said who the 'we' is that decided this.  Also, as the spec author, I<br>
>> had a conversation with you all but there was no decision at the end of it<br>
>> (I presume that came afterward) and I feel that I have a reasonable right to<br>
>> be involved.  Could you at least summarise your reasoning here?<br>
>><br>
>> I admit that I prefer this to be in core, but I'm not terribly choosy and<br>
>> that's not why I'm asking.  I'm more concerned that this is changing our<br>
>> mind at literally the last moment, and in turn wasting a developer's time,<br>
>> when there was a perfectly good process to debate this before coding was<br>
>> begun, and again when the code was up for review, both of which apparently<br>
>> failed.  I'd like to understand how we avoid getting here again in the<br>
>> future.  I'd also like to be certain we are not simply reversing a choice on<br>
>> a whim.<br>
>> --<br>
>> Ian.<br>
>><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>
><br>
><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>
<br>
<br>
<br>
</div></div><span><font color="#888888">--<br>
Akihiro Motoki <<a href="mailto:amotoki@gmail.com" target="_blank">amotoki@gmail.com</a>><br>
</font></span><div><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>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>