Re: [openstack-dev] [Neutron] Neutron extenstions
Hi Doug, On Thu, 19 Mar 2015 10:01:54 -0600 Doug Wiegley doug...@parksidesoftware.com wrote: 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? So speaking from a Nova (and more general) API point of view where we're probably a bit longer along the extensions/microversioning path, I think even with backwards compatibility it is still an issue. For example, without some sort of co-operative and strong input validation are you going to detect when someone sends a new parameter that is simply mispelled and all the other extensions assume that someone will look after it and return an appropriate rather than let it just through. Over time we've found a few examples even in our api request samples typos (which feeds into the docs) which are not detected just because of this situation. Chris Thanks, doug On Mar 19, 2015, at 6:37 AM, Gary Kotton gkot...@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 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 2:32 PM To: OpenStack List openstack-dev@lists.openstack.org mailto: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 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 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-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
Re: [openstack-dev] [Neutron] Neutron extenstions
Hi, Regarding setting the MTU on the API level: this was my bad. This is a read only value. The MTU is learnt from the plugin. Thanks Gary From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Saturday, March 21, 2015 at 12:49 AM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron] Neutron extenstions It's good to have trackers for cleaning up the implementation of these features. I hope we might be able soon to provide more details concerning what cleaning up activities should happen here. Core vs extension is often incorrectly misunderstood for essential vs optional. I believe this classification is wrong, in my opinion. Indeed I believe that there will be a lot of people who consider the network entity optional (why not just create subnets?), whereas there are a lot of people who consider the floating IP concept essential (ever tried to run any sort of app on OpenStack clouds without them?). The API extensions serve two purposes: flexibility and evolution of the API. While they've been successful at the former (even too much), they've been a bit of failure at the latter. This is why, as Akihiro suggested, we would like to move away from extensions as a mechanisms for evolving the API, through a process which starts with condensing a lot of them into a super-core or unified API. On the other hand, it is also important to note that this plan has not been approved anywhere, so reviewers, in theory should stick to the everything is an extension model. Now everything I wrote in the last paragraphs is of little to no importance in the present situation. I think the answers we want are: 1) Does it make sense to present these attributes to *all* users? 2) If the answer to #1 is yes, what should be the correct behaviour for plugins which are unable to understand these new attributes? I think this is probably a good point to separate the discussion between the MTU extension and the vlan_transparent one. The MTU issue has been a long-standing problem for neutron users. What this extension is doing is simply, in my opinion, enabling API control over an aspect users were dealing with previously through custom made scripts. It solves a fundamental issue, and it seems like it does that in a reasonable way. The implementation is also complete, in the sense that there is a component shipped with neutron which supports it - the DHCP agent. It's not merely a management layer change that then somehow something will implement. My personal opinion is that I welcome an appropriate MTU management. Is not exposing details of the backend technology as it's the tenant network MTU we are talking about. If a plugin does not support specifically setting the MTU parameter, I would raise a 500 NotImplemented error. This will probably create a precedent, but as I also stated in the past, I tend to believe this might actually be better than the hide seek game we do with extension. The vlan_transparent feature serves a specific purpose of a class of applications - NFV apps. The requirement is well understood, and the goal of these feature is to support exactly this; It has been speculated during the review process whether this was actually a provider network attribute. In theory it is something that characterises how the network should be implemented in the backend. However it was not possible to make this ad admin attribute because also non-admins might require a vlan_transparent network. Proper RBAC might allow us to expose this attribute only to a specific class of users, but Neutron does not yet have RBAC [1] Because of its nature vlan_transparent is an attribute that probably several plugins will not be able to understand. Regardless of what the community decides regardless extensions vs non-extension, the code as it is implies that this flag is present in every request - defaulting to False. This can lead to somewhat confusing situation, because users can set it to True, and a get a 200 response. As a user, I would think that Neutron has prepared for me a nice network which is vlan transparent... but if Neutron is running any plugin which does not support this extension I would be in a for a huge disappointment when I discover my network is not vlan transparent at all! Users need feedback, and need consistency between the desired state they express in the API and the actual state which is implemented in the control plane. I think this is something which should be fixed in the cleanup activities. I reckon that perhaps, as a short term measure, the configuration flag Armando mentioned might be used to obscure completely the API attribute if a deployer chooses not to support vlan transparent networks. Anyway, since I did not follow the review of the implementation I'll leave
Re: [openstack-dev] [Neutron] Neutron extenstions
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. 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
Re: [openstack-dev] [Neutron] Neutron extenstions
On 20 March 2015 at 15:49, Salvatore Orlando sorla...@nicira.com wrote: The MTU issue has been a long-standing problem for neutron users. What this extension is doing is simply, in my opinion, enabling API control over an aspect users were dealing with previously through custom made scripts. Actually, version 1 is not even doing that; it's simply telling the user what happened, which the user has never previously been able to tell, and configuring the network consistently. I don't think we implemented the 'choose an MTU' API, we're simply telling you the MTU you got. Since this is frequently smaller than you think (there are some non-standard features that mean you frequently *can* pass larger packets than should really work, hiding the problem at the cost of a performance penalty for doing it) and there was previously no way of getting any idea of what it is, this is a big step forward. And to reiterate, because this point is often missed: different networks in Neutron have different MTUs. My virtual networks might be 1450. My external network might be 1500. The provider network to my NFS server might be 9000. There is *nothing* in today's Neutron that lets you do anything about that, and - since Neutron routers and Neutron DHCP agents have no means of dealing with different MTU networks - really strange things happen if you try some sort of workaround. If a plugin does not support specifically setting the MTU parameter, I would raise a 500 NotImplemented error. This will probably create a precedent, but as I also stated in the past, I tend to believe this might actually be better than the hide seek game we do with extension. I am totally happy with this, if we agree it's what we want to do, and it makes plenty of sense for when you request an MTU. The other half of the interface is when you don't request a specific MTU but you'd like to know what MTU you got - the approach we have today is that if the MTU can't be determined (either a plugin with no support or one that's short on information) then the value on the network object is unset. I assume people are OK with that. The vlan_transparent feature serves a specific purpose of a class of applications - NFV apps. To be pedantic - the uses for it are few and far between but I wouldn't reduce it to 'NFV apps'. http://virl.cisco.com/ I wrote on Openstack a couple of years ago and it's network simulation but not actually NFV. People implementing resold services (...aaS) in VMs would quite like VLANs on their virtual networks too, and this has been discussed in at least 3 summits so far. I'm sure other people can come up with creative reasons. It has been speculated during the review process whether this was actually a provider network attribute. Which it isn't, just for reference. In theory it is something that characterises how the network should be implemented in the backend. However it was not possible to make this ad admin attribute because also non-admins might require a vlan_transparent network. Proper RBAC might allow us to expose this attribute only to a specific class of users, but Neutron does not yet have RBAC [1] I think it's a little early to worry about restricting the flag. The default implementation pretty much returns a constant (and says if that constant is true when you'd like it to be) - it's implemented as a call for future expansion. Because of its nature vlan_transparent is an attribute that probably several plugins will not be able to understand. And again backward compatibility is documented, and actually pretty horrible now I come to reread it, so if we wanted to go with a 500 as above that's quite reasonable. Regardless of what the community decides regardless extensions vs non-extension, the code as it is implies that this flag is present in every request - defaulting to False. Which is, in fact, not correct (or at least not the way it's supposed to be, anyway; I need to check the code). The original idea was that if it's not present in the request then you can't assume the network you're returned is a VLAN trunk, but you also can't assume it isn't - as in, it's the same as the current behaviour, where the plugin does what it does and you get to put up with the results. The difference is that the plugin now gets to tell you what it's done. This can lead to somewhat confusing situation, because users can set it to True, and a get a 200 response. As a user, I would think that Neutron has prepared for me a nice network which is vlan transparent... but if Neutron is running any plugin which does not support this extension I would be in a for a huge disappointment when I discover my network is not vlan transparent at all! The spec has detail on how the user works this out, as I say. Unfortunately it's not by return code I reckon that perhaps, as a short term measure, the configuration flag Armando mentioned might be used to obscure completely the API attribute
Re: [openstack-dev] [Neutron] Neutron extenstions
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.commailto:gkot...@vmware.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto: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.orgmailto: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.ukmailto:ijw.ubu...@cack.org.uk Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 8:44 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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=1138958https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1138958d=AwMFaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=NzYY0bOpToH9ZNwzqI_SpQHiPFRXD_nfb1bM3qAw7Css=FlF57GYJqeWgx5ivxnK5kfWlyTIc1ZFbdlXoi2cfdhwe= (admittedly first link I found, but there's no shortage of them) On 19 March 2015 at 05:32, Gary Kotton gkot...@vmware.commailto: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.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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:unsubscribehttp://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
Re: [openstack-dev] [Neutron] Neutron extenstions
I agree with a lot of your desires, but not your reasoning as to why the changes are problematic. Also, your statements about API changes are pretty reasonable and probably want writing down somewhere so that future specs are evaluated against them. Firstly, if we add to the core Neutron interface it's clear that old plugins have to behave sensibly. If we add an MTU attribute or a VLAN attribute and we allow the user to tinker with it (in the case of MTU that's a future plan, but in the VLAN case that's true now) then there has to be a backward compatibility plan - we can't have plugins appearing as if they support the functionality when they actually ignored the request. The specs are quite explicit about that and how to make sure it doesn't work that way, so your criticism about not correctly implementing the opt-in approach does not apply. They're not aiming for an opt-in approach but an opt-out one; they're aiming to add an attribute and ensure that unaware, unchanged plugins respect the proposed API behaviour. That being the case, neither the MTU plugin not the VLAN plugin require support from the driver or plugin to work. If the current patches do not implement the model, and in particular if they work as you describe, then they are indeed broken (not to spec, specifically) and need to be fixed. The specs are quite clear about what should happen in those cases, and what you're describing is a bug in the code, not a flaw in the proposed design - I'll get someone to take a look, but can you file it so that it doesn't get lost, along with a way to trigger it? I think that, in these circumstances, the intended behaviour is logical and in line with what you want to see. If you are still interested in either or both of them being extensions rather than core attributes, then that's fine and something we should discuss further, but I don't think what you've said here is justification. -- Ian. On 19 March 2015 at 16:23, Armando M. arma...@gmail.com wrote: 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]
Re: [openstack-dev] [Neutron] Neutron extenstions
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
Re: [openstack-dev] [Neutron] Neutron extenstions
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]
Re: [openstack-dev] [Neutron] Neutron extenstions
It's good to have trackers for cleaning up the implementation of these features. I hope we might be able soon to provide more details concerning what cleaning up activities should happen here. Core vs extension is often incorrectly misunderstood for essential vs optional. I believe this classification is wrong, in my opinion. Indeed I believe that there will be a lot of people who consider the network entity optional (why not just create subnets?), whereas there are a lot of people who consider the floating IP concept essential (ever tried to run any sort of app on OpenStack clouds without them?). The API extensions serve two purposes: flexibility and evolution of the API. While they've been successful at the former (even too much), they've been a bit of failure at the latter. This is why, as Akihiro suggested, we would like to move away from extensions as a mechanisms for evolving the API, through a process which starts with condensing a lot of them into a super-core or unified API. On the other hand, it is also important to note that this plan has not been approved anywhere, so reviewers, in theory should stick to the everything is an extension model. Now everything I wrote in the last paragraphs is of little to no importance in the present situation. I think the answers we want are: 1) Does it make sense to present these attributes to *all* users? 2) If the answer to #1 is yes, what should be the correct behaviour for plugins which are unable to understand these new attributes? I think this is probably a good point to separate the discussion between the MTU extension and the vlan_transparent one. The MTU issue has been a long-standing problem for neutron users. What this extension is doing is simply, in my opinion, enabling API control over an aspect users were dealing with previously through custom made scripts. It solves a fundamental issue, and it seems like it does that in a reasonable way. The implementation is also complete, in the sense that there is a component shipped with neutron which supports it - the DHCP agent. It's not merely a management layer change that then somehow something will implement. My personal opinion is that I welcome an appropriate MTU management. Is not exposing details of the backend technology as it's the tenant network MTU we are talking about. If a plugin does not support specifically setting the MTU parameter, I would raise a 500 NotImplemented error. This will probably create a precedent, but as I also stated in the past, I tend to believe this might actually be better than the hide seek game we do with extension. The vlan_transparent feature serves a specific purpose of a class of applications - NFV apps. The requirement is well understood, and the goal of these feature is to support exactly this; It has been speculated during the review process whether this was actually a provider network attribute. In theory it is something that characterises how the network should be implemented in the backend. However it was not possible to make this ad admin attribute because also non-admins might require a vlan_transparent network. Proper RBAC might allow us to expose this attribute only to a specific class of users, but Neutron does not yet have RBAC [1] Because of its nature vlan_transparent is an attribute that probably several plugins will not be able to understand. Regardless of what the community decides regardless extensions vs non-extension, the code as it is implies that this flag is present in every request - defaulting to False. This can lead to somewhat confusing situation, because users can set it to True, and a get a 200 response. As a user, I would think that Neutron has prepared for me a nice network which is vlan transparent... but if Neutron is running any plugin which does not support this extension I would be in a for a huge disappointment when I discover my network is not vlan transparent at all! Users need feedback, and need consistency between the desired state they express in the API and the actual state which is implemented in the control plane. I think this is something which should be fixed in the cleanup activities. I reckon that perhaps, as a short term measure, the configuration flag Armando mentioned might be used to obscure completely the API attribute if a deployer chooses not to support vlan transparent networks. Anyway, since I did not follow the review of the implementation I'll leave to the authors and reviewers any comment pertaining implementation. One more thing I do not see is how a transparent VLAN is implemented. Going back to the spec history it is unclear whether this was at all in the scope of this spec. Indeed it seems this feature simply gives a ML2 driver a solution to specify whether it support transparent networks or not, and then inform the user in a fairly backend-agnostic way. Indeed, quoting comment in the spec review [2]: there's no change to the implementation of the networking because we're not changing it -
Re: [openstack-dev] [Neutron] Neutron extenstions
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
Re: [openstack-dev] [Neutron] Neutron extenstions
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 gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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 gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron extenstions
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 gkot...@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.lo...@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 doug...@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 gkot...@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 gkot...@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 gkot...@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-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
Re: [openstack-dev] [Neutron] Neutron extenstions
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.lo...@rackspace.commailto:brandon.lo...@rackspace.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 6:20 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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 doug...@parksidesoftware.commailto:doug...@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 gkot...@vmware.commailto:gkot...@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 gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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 gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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.orgmailto: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
Re: [openstack-dev] [Neutron] Neutron extenstions
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Neutron extenstions
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 s...@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-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
Re: [openstack-dev] [Neutron] Neutron extenstions
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
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 doug...@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 gkot...@vmware.commailto:gkot...@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 gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 2:32 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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 gkot...@vmware.commailto:gkot...@vmware.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Thursday, March 19, 2015 at 1:14 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto: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.orgmailto: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
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 gkot...@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 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 2:32 PM To: OpenStack List openstack-dev@lists.openstack.org mailto: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 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 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-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
Re: [openstack-dev] [Neutron] Neutron extenstions
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
