settingsLogin | Registersettings

Re: [openstack-dev] [Neutron] Neutron extenstions

0 votes

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes - mtu and vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton <gkotton@vmware.comgkotton@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.orgopenstack-dev@lists.openstack.org>
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List <openstack-dev@lists.openstack.orgopenstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton <gkotton@vmware.comgkotton@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.orgopenstack-dev@lists.openstack.org>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List <openstack-dev@lists.openstack.orgopenstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others.
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 (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid.
Thanks
Gary


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Mar 19, 2015 in openstack-dev by Gary_Kotton (17,280 points)   3 4 9
retagged Apr 14, 2015 by admin

18 Responses

0 votes

On Thu, Mar 19, 2015 at 05:37:59AM PDT, Gary Kotton wrote:
In my opinion these should be added as separate extensions.

The spec that was approved for these patches does list the new attribute as being
added to the Network object.

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html#rest-api-impact

--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Sean_M._Collins (11,480 points)   3 7 9
0 votes

Hi Gary,

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?

Thanks,
doug

On Mar 19, 2015, at 6:37 AM, Gary Kotton gkotton@vmware.com wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921 https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420 https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes – mtu and vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton <gkotton@vmware.com gkotton@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - https://review.openstack.org/#/c/154921 https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton <gkotton@vmware.com gkotton@vmware.com>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List <openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420 https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others.
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 (https://review.openstack.org/#/c/165776 https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid.
Thanks
Gary


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by dougwig_at_parksides (7,230 points)   1 2 3
0 votes

?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?

Thanks,

Brandon


From: Doug Wiegley dougwig@parksidesoftware.com
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

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?

Thanks,
doug

On Mar 19, 2015, at 6:37 AM, Gary Kotton gkotton@vmware.com wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes - mtu and vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton gkotton@vmware.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton gkotton@vmware.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others.
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 (https://review.openstack.org/#/c/165776/) - please feel free to knack if it is invalid.
Thanks
Gary


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Brandon_Logan (9,580 points)   1 2 5
0 votes

Hi,
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.
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).
I really think that we need to revert these and have the extensions done in the standard fasion.
Thanks
Gary

From: Brandon Logan brandon.logan@RACKSPACE.COM
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 6:20 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

​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?

Thanks,

Brandon


From: Doug Wiegley dougwig@parksidesoftware.com
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

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?

Thanks,
doug

On Mar 19, 2015, at 6:37 AM, Gary Kotton gkotton@vmware.com wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes – mtu and vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton gkotton@vmware.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton gkotton@vmware.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base attributes for the networks. Is there any reason why this was not added as a separate extension like all others.
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 (https://review.openstack.org/#/c/165776/) – please feel free to knack if it is invalid.
Thanks
Gary


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Gary_Kotton (17,280 points)   3 4 9
0 votes

There are precedents for this. For example, the attributes that currently
exist for IPv6 advertisement are very similar:

  • added during the run of a stable Neutron API
  • properties added on a Neutron object (MTU and VLAN affect network, but
    IPv6 affects subnet - same principle though)
  • settable, but with defaults so they're optional
  • turn up in output when the subnet information is fetched

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.

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?
--
Ian.

On 19 March 2015 at 10:07, Gary Kotton gkotton@vmware.com wrote:

Hi,
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.
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).
I really think that we need to revert these and have the extensions done
in the standard fasion.
Thanks
Gary

From: Brandon Logan brandon.logan@RACKSPACE.COM
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 6:20 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

​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?

Thanks,

Brandon


From: Doug Wiegley dougwig@parksidesoftware.com
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

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?

Thanks,
doug

On Mar 19, 2015, at 6:37 AM, Gary Kotton gkotton@vmware.com wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble
opinion):
https://review.openstack.org/#/c/154921/ and
https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes – mtu
and vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and
https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton gkotton@vmware.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too -
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton gkotton@vmware.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base
attributes for the networks. Is there any reason why this was not added as
a separate extension like all others.
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 (
https://review.openstack.org/#/c/165776/) – please feel free to knack if
it is invalid.
Thanks
Gary


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Ian_Wells (5,300 points)   1 2 5
0 votes

On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote:
There are precedents for this. For example, the attributes that currently
exist for IPv6 advertisement are very similar:

I'll also note that the API changes landed in Icehouse, but the
implementation missed the Icehouse deadline and was landed in Juno, so
for a time the attributes were hidden from users.

https://review.openstack.org/#/c/85869/
--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Sean_M._Collins (11,480 points)   3 7 9
0 votes

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.
Thanks
Gary

On 3/19/15, 8:30 PM, "Sean M. Collins" sean@coreitpro.com wrote:

On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote:
There are precedents for this. For example, the attributes that
currently
exist for IPv6 advertisement are very similar:

I'll also note that the API changes landed in Icehouse, but the
implementation missed the Icehouse deadline and was landed in Juno, so
for a time the attributes were hidden from users.

https://review.openstack.org/#/c/85869/
--
Sean M. Collins


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Gary_Kotton (17,280 points)   3 4 9
0 votes

On 19 March 2015 at 11:44, Gary Kotton gkotton@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Ian_Wells (5,300 points)   1 2 5
0 votes

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@cack.org.uk wrote:

On 19 March 2015 at 11:44, Gary Kotton gkotton@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 19, 2015 by Armando_M. (23,560 points)   2 4 8
0 votes

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.

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@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@cack.org.uk wrote:

On 19 March 2015 at 11:44, Gary Kotton gkotton@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@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@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Akihiro Motoki amotoki@gmail.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Mar 20, 2015 by Akihiro_Motoki (8,520 points)   2 3 4
...