[openstack-dev] [Neutron] Neutron extenstions

Armando M. armamig at gmail.com
Fri Mar 20 18:54:01 UTC 2015


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. <armamig at gmail.com> wrote:

>
>
> On 19 March 2015 at 23:59, Akihiro Motoki <amotoki at 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. <armamig at 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.ubuntu at cack.org.uk> wrote:
>> >>
>> >> On 19 March 2015 at 11:44, Gary Kotton <gkotton at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>>
>>
>> --
>> Akihiro Motoki <amotoki at gmail.com>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150320/4c79a9ab/attachment.html>


More information about the OpenStack-dev mailing list