settingsLogin | Registersettings

[openstack-dev] [Neutron] VLAN transparency support

0 votes

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 10
retagged Apr 14, 2015 by admin

6 Responses

0 votes

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
responded Mar 19, 2015 by Gary_Kotton (17,280 points)   3 4 10
0 votes

Per the other discussion on attributes, I believe the change walks in
historical footsteps and it's a matter of project policy choice. That
aside, you raised a couple of other issues on IRC:

  • backward compatibility with plugins that haven't adapted their API - this
    is addressed in the spec, which should have been implemented in the patches
    (otherwise I will downvote the patch myself) - behaviour should be as
    before with the additional feature that you can now tell more about what
    the plugin is thinking
  • whether they should be core or an extension - this is a more personal
    opinion, but on the grounds that all networks are either trunks or not, and
    all networks have MTUs, I think they do want to be core. I would like to
    see plugin developers strongly encouraged to consider what they can do on
    both elements, whereas an extension tends to sideline functionality from
    view so that plugin writers don't even know it's there for consideration.

Aside from that, I'd like to emphasise the value of these patches, so
hopefully we can find a way to get them in in some form in this cycle. I
admit I'm interested in them because they make it easier to do NFV. But
they also help normal cloud users and operators, who otherwise have to do
some really strange things [1]. I think it's maybe a little unfair to post
reversion patches before discussion, particularly when the patch works,
passes tests and implements an approved spec correctly.
--
Ian.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958 (admittedly first
link I found, but there's no shortage of them)

On 19 March 2015 at 05:32, Gary Kotton gkotton@vmware.com wrote:

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 Ian_Wells (5,300 points)   1 2 5
0 votes

With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually <= the supported MTU on the network. I did not see this in the code (maybe I missed something).

From: Ian Wells ijw.ubuntu@cack.org.uk
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 8:44 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC:

  • backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, which should have been implemented in the patches (otherwise I will downvote the patch myself) - behaviour should be as before with the additional feature that you can now tell more about what the plugin is thinking
  • whether they should be core or an extension - this is a more personal opinion, but on the grounds that all networks are either trunks or not, and all networks have MTUs, I think they do want to be core. I would like to see plugin developers strongly encouraged to consider what they can do on both elements, whereas an extension tends to sideline functionality from view so that plugin writers don't even know it's there for consideration.

Aside from that, I'd like to emphasise the value of these patches, so hopefully we can find a way to get them in in some form in this cycle. I admit I'm interested in them because they make it easier to do NFV. But they also help normal cloud users and operators, who otherwise have to do some really strange things [1]. I think it's maybe a little unfair to post reversion patches before discussion, particularly when the patch works, passes tests and implements an approved spec correctly.
--
Ian.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1138958&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=NzYY0bOpToH9ZNwzqI_SpQHiPFRXD_nfb1bM3qAw7Cs&s=FlF57GYJqeWgx5ivxnK5kfWlyTIc1ZFbdlXoi2cfdhw&e= (admittedly first link I found, but there's no shortage of them)

On 19 March 2015 at 05:32, Gary Kotton gkotton@vmware.com wrote:
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 10
0 votes

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 12:01, Gary Kotton gkotton@vmware.com wrote:

With regards to the MTU can you please point me to where we validate
that the MTU defined by the tenant is actually <= the supported MTU on the
network. I did not see this in the code (maybe I missed something).

From: Ian Wells ijw.ubuntu@cack.org.uk
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 8:44 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Per the other discussion on attributes, I believe the change walks in
historical footsteps and it's a matter of project policy choice. That
aside, you raised a couple of other issues on IRC:

On 19 March 2015 at 05:32, Gary Kotton gkotton@vmware.com wrote:

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 Armando_M. (23,560 points)   2 5 8
0 votes

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 7:33 GMT+09:00 Armando M. armamig@gmail.com:

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 12:01, Gary Kotton gkotton@vmware.com wrote:

With regards to the MTU can you please point me to where we validate that
the MTU defined by the tenant is actually <= the supported MTU on the
network. I did not see this in the code (maybe I missed something).

From: Ian Wells ijw.ubuntu@cack.org.uk
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 8:44 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Per the other discussion on attributes, I believe the change walks in
historical footsteps and it's a matter of project policy choice. That
aside, you raised a couple of other issues on IRC:

  • backward compatibility with plugins that haven't adapted their API -
    this is addressed in the spec, which should have been implemented in the
    patches (otherwise I will downvote the patch myself) - behaviour should be
    as before with the additional feature that you can now tell more about what
    the plugin is thinking
  • whether they should be core or an extension - this is a more personal
    opinion, but on the grounds that all networks are either trunks or not, and
    all networks have MTUs, I think they do want to be core. I would like to
    see plugin developers strongly encouraged to consider what they can do on
    both elements, whereas an extension tends to sideline functionality from
    view so that plugin writers don't even know it's there for consideration.

Aside from that, I'd like to emphasise the value of these patches, so
hopefully we can find a way to get them in in some form in this cycle. I
admit I'm interested in them because they make it easier to do NFV. But
they also help normal cloud users and operators, who otherwise have to do
some really strange things [1]. I think it's maybe a little unfair to post
reversion patches before discussion, particularly when the patch works,
passes tests and implements an approved spec correctly.
--
Ian.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958 (admittedly first
link I found, but there's no shortage of them)

On 19 March 2015 at 05:32, Gary Kotton gkotton@vmware.com wrote:

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

--
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 5
0 votes

Hi,
So at the moment we have something that is half baked. Say we take the MTU support as an example: There is a configuration flag ‘advertise_mtu’ (the default value is False) – this is set by an admin, but a tenant can define the mtu setting when creating a network.
So by default the tenant setting are ignored.

So I suggest the following:
1. https://github.com/openstack/neutron/blob/master/neutron/api/v2/attributes.py#L697

  • we do a convertto': convertto_int (if someone passes any other type here it will break the dnsmasq
  • We add in another validation that checks against the configuration. It should throw an exception if the tenant has set an MTU and the admin has not set the advertise_mtu flag

We can take the similar approach to the ‘vlan_transparent’ but I have no idea what that actually means as part of the API. I am really not in favor of this even being in core.

Thanks
Gary

From: "Armando M." armamig@gmail.com
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Friday, March 20, 2015 at 12:33 AM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

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 12:01, Gary Kotton gkotton@vmware.com wrote:
With regards to the MTU can you please point me to where we validate that the MTU defined by the tenant is actually <= the supported MTU on the network. I did not see this in the code (maybe I missed something).

From: Ian Wells ijw.ubuntu@cack.org.uk
Reply-To: OpenStack List openstack-dev@lists.openstack.org
Date: Thursday, March 19, 2015 at 8:44 PM
To: OpenStack List openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Per the other discussion on attributes, I believe the change walks in historical footsteps and it's a matter of project policy choice. That aside, you raised a couple of other issues on IRC:

  • backward compatibility with plugins that haven't adapted their API - this is addressed in the spec, which should have been implemented in the patches (otherwise I will downvote the patch myself) - behaviour should be as before with the additional feature that you can now tell more about what the plugin is thinking
  • whether they should be core or an extension - this is a more personal opinion, but on the grounds that all networks are either trunks or not, and all networks have MTUs, I think they do want to be core. I would like to see plugin developers strongly encouraged to consider what they can do on both elements, whereas an extension tends to sideline functionality from view so that plugin writers don't even know it's there for consideration.

Aside from that, I'd like to emphasise the value of these patches, so hopefully we can find a way to get them in in some form in this cycle. I admit I'm interested in them because they make it easier to do NFV. But they also help normal cloud users and operators, who otherwise have to do some really strange things [1]. I think it's maybe a little unfair to post reversion patches before discussion, particularly when the patch works, passes tests and implements an approved spec correctly.
--
Ian.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1138958<https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1138958&d=AwMFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=NzYY0bOpToH9ZNwzqI_SpQHiPFRXD_nfb1bM3qAw7Cs&s=FlF57GYJqeWgx5ivxnK5kfWlyTIc1ZFbdlXoi2cfdhw&e= (admittedly first link I found, but there's no shortage of them)

On 19 March 2015 at 05:32, Gary Kotton gkotton@vmware.com wrote:
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 20, 2015 by Gary_Kotton (17,280 points)   3 4 10
...