The MTU values are derived from the config values only. If the tenant tries to set the MTU directly, that is rejected.
Rob From: Gary Kotton <gkot...@vmware.com<mailto:gkot...@vmware.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, March 19, 2015 at 3:01 PM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Neutron] VLAN transparency support 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.ubu...@cack.org.uk<mailto:ijw.ubu...@cack.org.uk>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, March 19, 2015 at 8:44 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto: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 <gkot...@vmware.com<mailto:gkot...@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 <gkot...@vmware.com<mailto:gkot...@vmware.com>> Reply-To: OpenStack List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List <openstack-dev@lists.openstack.org<mailto: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-requ...@lists.openstack.org?subject:unsubscribe<http://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
