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