Re: [openstack-dev] [neutron] L2 gateway as a service
On 20 November 2014 02:19, Sukhdev Kapur sukhdevka...@gmail.com wrote: Folks, Like Ian, I am jumping in this very late as well - as I decided to travel Europe after the summit, just returned back and catching up :-):-) I have noticed that this thread has gotten fairly convoluted and painful to read. I think Armando summed it up well in the beginning of the thread. There are basically three written proposals (listed in Armando's email - I pasted them again here). [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ In this thread I have seen other specs being mentioned as related. Namely: 1) https://review.openstack.org/#/c/93329/ (BGP VPN) 2) https://review.openstack.org/#/c/101043/ (MPLS vpn) 3) https://review.openstack.org/#/c/87825/ (external device integration) Note that I am not saying they should be put as well in the mix. I'm only listing them here as a recap. There are probably other ideas not yet put in the form of a concrete specification. In order to avoid further confusion, I would just blindly ignore proposals which do not exist in the form a specification. On this thread I see that the authors of first two proposals have already agreed to consolidate and work together. This leaves with two proposals. Both Ian and I were involved with the third proposal [3] and have reasonable idea about it. IMO, the use cases addressed by the third proposal are very similar to use cases addressed by proposal [1] and [2]. I can volunteer to follow up with Racha and Stephen from Ericsson to see if their use case will be covered with the new combined proposal. If yes, we have one converged proposal. If no, then we modify the proposal to accommodate their use case as well. Regardless, I will ask them to review and post their comments on [1]. One thing that I've noticed in the past is that contributors are led to think that the owner of the specification will also be the lead for the subsequent work. There nothing farther from truth. Sometimes I write specs with the exact intent of having somebody else lead the implementation. So don't feel bad to abandon a spec if you realize your use cases can be completely included in another specification. Having said that, this covers what we discussed during the morning session on Friday in Paris. Now, comes the second part which Ian brought up in the afternoon session on Friday. My initial reaction was, when heard his use case, that this new proposal/API should cover that use case as well (I am being bit optimistic here :-)). If not, rather than going into the nitty gritty details of the use case, let's see what modification is required to the proposed API to accommodate Ian's use case and adjust it accordingly. Unfortunately I did not attend that discussion. Possibly 90% of the people reading this thread did not attend it. It would be nice if Ian or somebody else posted a write-up, adding more details to what has already been shared in this thread. If you've already done so please share a link as my google-fu is not that good these days. Now, the last point (already brought up by Salvatore as well as Armando) - the abstraction of the API, so that it meets the Neutron API criteria. I think this is the critical piece. I also believe the API proposed by [1] is very close. We should clean it up and take out references to ToR's or physical vs virtual devices. The API should work at an abstract level so that it can deal with both physical as well virtual devices. If we can agree to that, I believe we can have a solid solution. Having said that I would like to request the community to review the proposal submitted by Maruti in [1] and post comments on the spec with the intent to get a closure on the API. I see lots of good comments already on the spec. Lets get this done so that we can have a workable (even if not perfect) version of API in Kilo cycle. Something which we can all start to play with. We can always iterate over it, and make change as we get more and more use cases covered. Iterate is the key here I believe. As long as we pretend to achieve the perfect API at the first attempt we'll just keep having this discussion. I think the first time a L2 GW API was proposed, it was for Grizzly. For instance, it might relatively easy to define an API which can handle both physical and virtual devices. The user workflow for a ToR terminated L2 GW is different from the workflow for a virtual appliance owned by tenant, and this will obviously reflected in the API. On the other hand, a BGP VPN might be a completely different use case, and therefore have a completely different set of APIs. Beyond APIs there are two more things to mention. First, we need some sort of open source reference implementation for every use case. For hardware VTEP obviously this won't be possible, but perhaps [1] can be used for integration tests. The
Re: [openstack-dev] [neutron] L2 gateway as a service
On 19 November 2014 17:19, Sukhdev Kapur sukhdevka...@gmail.com wrote: Folks, Like Ian, I am jumping in this very late as well - as I decided to travel Europe after the summit, just returned back and catching up :-):-) I have noticed that this thread has gotten fairly convoluted and painful to read. I think Armando summed it up well in the beginning of the thread. There are basically three written proposals (listed in Armando's email - I pasted them again here). [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ On this thread I see that the authors of first two proposals have already agreed to consolidate and work together. This leaves with two proposals. Both Ian and I were involved with the third proposal [3] and have reasonable idea about it. IMO, the use cases addressed by the third proposal are very similar to use cases addressed by proposal [1] and [2]. I can volunteer to follow up with Racha and Stephen from Ericsson to see if their use case will be covered with the new combined proposal. If yes, we have one converged proposal. If no, then we modify the proposal to accommodate their use case as well. Regardless, I will ask them to review and post their comments on [1]. Having said that, this covers what we discussed during the morning session on Friday in Paris. Now, comes the second part which Ian brought up in the afternoon session on Friday. My initial reaction was, when heard his use case, that this new proposal/API should cover that use case as well (I am being bit optimistic here :-)). If not, rather than going into the nitty gritty details of the use case, let's see what modification is required to the proposed API to accommodate Ian's use case and adjust it accordingly. As far as I can see, the question of whether you mark a network as 'edge' and therefore bridged to something you don't know about (my proposal) or whether you attach a block to it that, behinds the scenes, bridges to something you don't know about (Maruti's, if you take out all of the details of *what* is being attached to from the API) are basically as good as each other. My API parallels the way that provider networks are used, because that's what I had in mind at the time; Maruti's uses a block rather than marking the network, and the only real difference that makes is that (a) you can attach many networks to one block (which doesn't really seem to bring anything special) and (b) uses a port to connect to the network (which is not massively helpful because there's nothing sensible you can put on the port; there may be many things behind the gateway). At this point it becomes a completely religious argument about which is better. I still prefer mine, from gut feel, but they are almost exactly equivalent at this point. Taking your statement above of 'let's take out the switch port stuff' then Maruti's use case would need to explain where that data goes. The point I made is that it becomes a Sisyphean task (endless and not useful) to introduce a data model and API to introduce this into Neutron via an API and that's what I didn't want to do. Can we address that question? -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Hi Sukhdev, Hope you enjoyed Europe ;) On 19 November 2014 17:19, Sukhdev Kapur sukhdevka...@gmail.com wrote: Folks, Like Ian, I am jumping in this very late as well - as I decided to travel Europe after the summit, just returned back and catching up :-):-) I have noticed that this thread has gotten fairly convoluted and painful to read. I think Armando summed it up well in the beginning of the thread. There are basically three written proposals (listed in Armando's email - I pasted them again here). [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ On this thread I see that the authors of first two proposals have already agreed to consolidate and work together. This leaves with two proposals. Both Ian and I were involved with the third proposal [3] and have reasonable idea about it. IMO, the use cases addressed by the third proposal are very similar to use cases addressed by proposal [1] and [2]. I can volunteer to follow up with Racha and Stephen from Ericsson to see if their use case will be covered with the new combined proposal. If yes, we have one converged proposal. If no, then we modify the proposal to accommodate their use case as well. Regardless, I will ask them to review and post their comments on [1]. Having said that, this covers what we discussed during the morning session on Friday in Paris. Now, comes the second part which Ian brought up in the afternoon session on Friday. My initial reaction was, when heard his use case, that this new proposal/API should cover that use case as well (I am being bit optimistic here :-)). If not, rather than going into the nitty gritty details of the use case, let's see what modification is required to the proposed API to accommodate Ian's use case and adjust it accordingly. Now, the last point (already brought up by Salvatore as well as Armando) - the abstraction of the API, so that it meets the Neutron API criteria. I think this is the critical piece. I also believe the API proposed by [1] is very close. We should clean it up and take out references to ToR's or physical vs virtual devices. The API should work at an abstract level so that it can deal with both physical as well virtual devices. If we can agree to that, I believe we can have a solid solution. Yes, I do think that the same API can target both: a 100% software solution for L2GW as well as one that may want to rely on hardware support, in the same spirit of any other Neutron API. I made the same point on spec [1]. Having said that I would like to request the community to review the proposal submitted by Maruti in [1] and post comments on the spec with the intent to get a closure on the API. I see lots of good comments already on the spec. Lets get this done so that we can have a workable (even if not perfect) version of API in Kilo cycle. Something which we can all start to play with. We can always iterate over it, and make change as we get more and more use cases covered. So far it seems like proposal [1] that has the most momentum. I'd like to consider [3] as one potential software implementation of the proposed API. As I mentioned earlier, I'd rather start with a well defined problem, free of any potential confusion or open to subjective interpretation; a loose API suffers from both pitfalls, hence my suggestion to go with API proposed in [1]. Make sense? cheers.. -Sukhdev On Tue, Nov 18, 2014 at 6:44 PM, Armando M. arma...@gmail.com wrote: Hi, On 18 November 2014 16:22, Ian Wells ijw.ubu...@cack.org.uk wrote: Sorry I'm a bit late to this, but that's what you get from being on holiday... (Which is also why there are no new MTU and VLAN specs yet, but I swear I'll get to them.) Ah! I hope it was good at least :) On 17 November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. So, the gist of what I said is that we have three, independent, use cases: - connecting two VMs that like to tag packets to each other (VLAN clean networks) - connecting many networks to a single VM (trunking ports) - connecting the outside world to a set of virtual networks We're discussing that last use case here. The point I was
Re: [openstack-dev] [neutron] L2 gateway as a service
On 20 November 2014 02:08, Salvatore Orlando sorla...@nicira.com wrote: On 20 November 2014 02:19, Sukhdev Kapur sukhdevka...@gmail.com wrote: Folks, Like Ian, I am jumping in this very late as well - as I decided to travel Europe after the summit, just returned back and catching up :-):-) I have noticed that this thread has gotten fairly convoluted and painful to read. I think Armando summed it up well in the beginning of the thread. There are basically three written proposals (listed in Armando's email - I pasted them again here). [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ In this thread I have seen other specs being mentioned as related. Namely: 1) https://review.openstack.org/#/c/93329/ (BGP VPN) 2) https://review.openstack.org/#/c/101043/ (MPLS vpn) 3) https://review.openstack.org/#/c/87825/ (external device integration) Note that I am not saying they should be put as well in the mix. I'm only listing them here as a recap. There are probably other ideas not yet put in the form of a concrete specification. In order to avoid further confusion, I would just blindly ignore proposals which do not exist in the form a specification. Ah, I know what you're trying to do here...I am not gonna fall into your trap :) On this thread I see that the authors of first two proposals have already agreed to consolidate and work together. This leaves with two proposals. Both Ian and I were involved with the third proposal [3] and have reasonable idea about it. IMO, the use cases addressed by the third proposal are very similar to use cases addressed by proposal [1] and [2]. I can volunteer to follow up with Racha and Stephen from Ericsson to see if their use case will be covered with the new combined proposal. If yes, we have one converged proposal. If no, then we modify the proposal to accommodate their use case as well. Regardless, I will ask them to review and post their comments on [1]. One thing that I've noticed in the past is that contributors are led to think that the owner of the specification will also be the lead for the subsequent work. There nothing farther from truth. Sometimes I write specs with the exact intent of having somebody else lead the implementation. So don't feel bad to abandon a spec if you realize your use cases can be completely included in another specification. Stating the obvious, but yes point taken! Having said that, this covers what we discussed during the morning session on Friday in Paris. Now, comes the second part which Ian brought up in the afternoon session on Friday. My initial reaction was, when heard his use case, that this new proposal/API should cover that use case as well (I am being bit optimistic here :-)). If not, rather than going into the nitty gritty details of the use case, let's see what modification is required to the proposed API to accommodate Ian's use case and adjust it accordingly. Unfortunately I did not attend that discussion. Possibly 90% of the people reading this thread did not attend it. It would be nice if Ian or somebody else posted a write-up, adding more details to what has already been shared in this thread. If you've already done so please share a link as my google-fu is not that good these days. Now, the last point (already brought up by Salvatore as well as Armando) - the abstraction of the API, so that it meets the Neutron API criteria. I think this is the critical piece. I also believe the API proposed by [1] is very close. We should clean it up and take out references to ToR's or physical vs virtual devices. The API should work at an abstract level so that it can deal with both physical as well virtual devices. If we can agree to that, I believe we can have a solid solution. Having said that I would like to request the community to review the proposal submitted by Maruti in [1] and post comments on the spec with the intent to get a closure on the API. I see lots of good comments already on the spec. Lets get this done so that we can have a workable (even if not perfect) version of API in Kilo cycle. Something which we can all start to play with. We can always iterate over it, and make change as we get more and more use cases covered. Iterate is the key here I believe. As long as we pretend to achieve the perfect API at the first attempt we'll just keep having this discussion. I think the first time a L2 GW API was proposed, it was for Grizzly. For instance, it might relatively easy to define an API which can handle both physical and virtual devices. The user workflow for a ToR terminated L2 GW is different from the workflow for a virtual appliance owned by tenant, and this will obviously reflected in the API. On the other hand, a BGP VPN might be a completely different use case, and therefore have a completely different set of APIs. +1
Re: [openstack-dev] [neutron] L2 gateway as a service
Sorry I'm a bit late to this, but that's what you get from being on holiday... (Which is also why there are no new MTU and VLAN specs yet, but I swear I'll get to them.) On 17 November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. So, the gist of what I said is that we have three, independent, use cases: - connecting two VMs that like to tag packets to each other (VLAN clean networks) - connecting many networks to a single VM (trunking ports) - connecting the outside world to a set of virtual networks We're discussing that last use case here. The point I was made was that: - there are more encaps in the world than just VLANs - they can all be solved in the same way using an edge API - if they are solved using an edge API, the job of describing the network you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or l2tpv3 endpoint data) is best kept outside of Neutron's API, because Neutron can't usefully do anything with it other than validate it and hand it off to whatever network control code is being used. (Note that most encaps will likely *not* be implemented in Neutron's inbuilt control code.) Now, the above argument says that we should keep this out of Neutron. The problem with that is that people are using the OVS mechanism driver and would like a solution that works with that, implying something that's *inside* Neutron. For that case, it's certainly valid to consider another means of implementation, but it wouldn't be my personal choice. (For what it's worth I'm looking at ODL based controller implementations, so this isn't an issue for me personally.) If one were to implement the code in the Neutron API, even as an extension, I would question whether it's a sensible thing to attempt before the RPC server/REST server split is done, since it also extends the API between them. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. There are lots of players interested in an API, that much is clear, and all the more so if you consider that this feature has strong analogies with use cases such as switch port exposure and MPLS. The problem is that it's clearly a fairly complex API with some variety of ways to implement it, and both of these things work against its acceptance. Additionally, per the above discussion, I would say it's not essential for it to be core Neutron functionality. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. Natural selection works poorly on APIs because once they exist they're hard to change and/or retire, due to backward compatibility requirements. To me, this is in the scope of the advanced services project. Advanced services or no, the point I was making is that this is not something that should fit under the Neutron API endpoint. Since it's not really related to any of the other advanced services it's not particularly necessary that it fit under the Advanced Services API endpoint either, although it could. My Unix design leanings say to me that if things are not related they shouldn't be combined, though - the simplest thing that does the job is the right answer. -- Ian. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Hi, On 18 November 2014 16:22, Ian Wells ijw.ubu...@cack.org.uk wrote: Sorry I'm a bit late to this, but that's what you get from being on holiday... (Which is also why there are no new MTU and VLAN specs yet, but I swear I'll get to them.) Ah! I hope it was good at least :) On 17 November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. So, the gist of what I said is that we have three, independent, use cases: - connecting two VMs that like to tag packets to each other (VLAN clean networks) - connecting many networks to a single VM (trunking ports) - connecting the outside world to a set of virtual networks We're discussing that last use case here. The point I was made was that: - there are more encaps in the world than just VLANs - they can all be solved in the same way using an edge API No disagreement all the way up to this point, assumed that I don't worry about what this edge API really is. - if they are solved using an edge API, the job of describing the network you're trying to bring in (be it switch/port/vlan, or MPLS label stack, or l2tpv3 endpoint data) is best kept outside of Neutron's API, because Neutron can't usefully do anything with it other than validate it and hand it off to whatever network control code is being used. (Note that most encaps will likely *not* be implemented in Neutron's inbuilt control code.) This is where the disagreement begins, as far as I am concerned; in fact we already have a well defined way of describing what a network entity in Neutron is, namely an L2 broadcast domain abstraction. An L2 gateway API that is well defined and well scoped should just express how one can be connected to another, nothing more, at least as a starting point. Now, the above argument says that we should keep this out of Neutron. The problem with that is that people are using the OVS mechanism driver and would like a solution that works with that, implying something that's *inside* Neutron. For that case, it's certainly valid to consider another means of implementation, but it wouldn't be my personal choice. (For what it's worth I'm looking at ODL based controller implementations, so this isn't an issue for me personally.) If one were to implement the code in the Neutron API, even as an extension, I would question whether it's a sensible thing to attempt before the RPC server/REST server split is done, since it also extends the API between them. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. There are lots of players interested in an API, that much is clear, and all the more so if you consider that this feature has strong analogies with use cases such as switch port exposure and MPLS. The problem is that it's clearly a fairly complex API with some variety of ways to implement it, and both of these things work against its acceptance. Additionally, per the above discussion, I would say it's not essential for it to be core Neutron functionality. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. Natural selection works poorly on APIs because once they exist they're hard to change and/or retire, due to backward compatibility requirements. Well, that is true assumed that someone can or is willing to use them :) To me, this is in the scope of the advanced services project. Advanced services or no, the point I was making is that this is not something that
Re: [openstack-dev] [neutron] L2 gateway as a service
Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at https://review.openstack.org/#/c/134179/ Thanks, Maruti ___ OpenStack-dev mailing list
Re: [openstack-dev] [neutron] L2 gateway as a service
On Nov 17, 2014, at 9:13 AM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. I think we need to be careful of the natural tendency to view the new project as a place to put everything that is moving too slowly in neutron. Certainly advanced services is one of the most obvious use cases of this functionality, but that doesn't mean that the notion of an SDN trunk port should live anywhere but neutron, IMO. Thanks, doug Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service
Re: [openstack-dev] [neutron] L2 gateway as a service
I think this thread is about the L2 gateway service... how's that related with the notion of trunk port? I know that the spec under review adds a component which is tantamount to a L2 gateway, but while the functionality is similar, the use case, and therefore the API exposed, are rather different. Am I missing something here? Salvatore On 17 November 2014 10:40, Doug Wiegley do...@a10networks.com wrote: On Nov 17, 2014, at 9:13 AM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. I think we need to be careful of the natural tendency to view the new project as a place to put everything that is moving too slowly in neutron. Certainly advanced services is one of the most obvious use cases of this functionality, but that doesn't mean that the notion of an SDN trunk port should live anywhere but neutron, IMO. Thanks, doug Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/
Re: [openstack-dev] [neutron] L2 gateway as a service
On Mon, Nov 17, 2014 at 10:13:50AM +0100, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi Hi. On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. I, Isaku, talked with Maruti and has agreed to pursue [1] with a hope to unify [2] and we will see the outcome in kilo cycle. I'm willing to review/help [1] (and corresponding patches). thanks, All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository
Re: [openstack-dev] [neutron] L2 gateway as a service
Sorry, it's early, I was being imprecise and using trunk to mean, methods to connect x to a neutron (l2 segment. Doug On Nov 17, 2014, at 10:35 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: I think this thread is about the L2 gateway service... how's that related with the notion of trunk port? I know that the spec under review adds a component which is tantamount to a L2 gateway, but while the functionality is similar, the use case, and therefore the API exposed, are rather different. Am I missing something here? Salvatore On 17 November 2014 10:40, Doug Wiegley do...@a10networks.commailto:do...@a10networks.com wrote: On Nov 17, 2014, at 9:13 AM, Mathieu Rohon mathieu.ro...@gmail.commailto:mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.commailto:arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. I think we need to be careful of the natural tendency to view the new project as a place to put everything that is moving too slowly in neutron. Certainly advanced services is one of the most obvious use cases of this functionality, but that doesn't mean that the notion of an SDN trunk port should live anywhere but neutron, IMO. Thanks, doug Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.commailto:igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.commailto:mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of
Re: [openstack-dev] [neutron] L2 gateway as a service
What would be the best meeting to discuss these works and any others related? Maybe, collectively, a very flexible solution for all related use cases could be found. I also want to go forward with some work I've developed a couple months ago, part of methods to connect x to a neutron l2 segment, which aims at any x, be it a 10-year old cheap home gateway wireless access point located at the other side of the planet, or a datacenter's hardware switch VLAN. Cheers, On 17 November 2014 12:29, Doug Wiegley do...@a10networks.com wrote: Sorry, it's early, I was being imprecise and using trunk to mean, methods to connect x to a neutron (l2 segment. Doug On Nov 17, 2014, at 10:35 AM, Salvatore Orlando sorla...@nicira.com wrote: I think this thread is about the L2 gateway service... how's that related with the notion of trunk port? I know that the spec under review adds a component which is tantamount to a L2 gateway, but while the functionality is similar, the use case, and therefore the API exposed, are rather different. Am I missing something here? Salvatore On 17 November 2014 10:40, Doug Wiegley do...@a10networks.com wrote: On Nov 17, 2014, at 9:13 AM, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. I think we need to be careful of the natural tendency to view the new project as a place to put everything that is moving too slowly in neutron. Certainly advanced services is one of the most obvious use cases of this functionality, but that doesn't mean that the notion of an SDN trunk port should live anywhere but neutron, IMO. Thanks, doug Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers,
Re: [openstack-dev] [neutron] L2 gateway as a service
On 17 November 2014 01:13, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi On Fri, Nov 14, 2014 at 6:26 PM, Armando M. arma...@gmail.com wrote: Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. Me neither, that's why I'd like ian, who led this discussion, to sum up the outcome from its point of view. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) I tend to agree, but I think that one of the reason why we are looking for a consensus, is because API evolutions proposed through Neutron-spec are rejected by core-dev, because they rely on external components (sdn controller, proprietary hardware...) or they are not a high priority for neutron core-dev. I am not sure I agree with this statement. I am not aware of any proposal here being dependent on external components as you suggested, but even if it were, an API can be implemented in multiple ways, just like the (core) Neutron API can be implemented using a fully open source solution or an external party like an SDN controller. By finding a consensus, we show that several players are interested in such an API, and it helps to convince core-dev that this use-case, and its API, is missing in neutron. Right, but it seems we are struggling to find this consensus. In this particular instance, where we are trying to address the use case of L2 Gateway (i.e. allow Neutron logical networks to be extended with physical ones), it seems that everyone has a different opinion as to what abstraction we should adopt in order to express and configure the L2 gateway entity, and at the same time I see no convergence in sight. Now if the specific L2 Gateway case were to be considered part of the core Neutron API, then such a consensus would be mandatory IMO, but if it isn't, is there any value in striving for that consensus at all costs? Perhaps not, and we can have multiple attempts experiment and innovate independently. So far, all my data points seem to imply that such an abstraction need not be part of the core API. Now, if there is room for easily propose new API in Neutron, It make sense to leave new API appear and evolve, and then let natural evolution take its course , as you said. To me, this is in the scope of the advanced services project. Advanced Services may be a misnomer, but an incubation feature, sure why not? Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those
Re: [openstack-dev] [neutron] L2 gateway as a service
Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at *https://review.openstack.org/#/c/134179/* https://review.openstack.org/ Thanks, Maruti ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at https://review.openstack.org/#/c/134179/ Thanks, Maruti ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at https://review.openstack.org/#/c/134179/ Thanks, Maruti ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Igor Duarte Cardoso. http://igordcard.com @igordcard https://twitter.com/igordcard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at https://review.openstack.org/#/c/134179/ Thanks, Maruti ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Igor Duarte Cardoso. http://igordcard.com @igordcard https://twitter.com/igordcard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Hi Salvatore, Thanks for the review comments on the BP. Yes, Maruti’s BP supersedes the review https://review.openstack.org/#/c/100278 posted by Isaku, and we discussed with Isaku during the summit to embrace his BP. For the review https://review.openstack.org/#/c/93613 by Racha , we were not able to see how that idea maps to implementation angle driven in Maruti’s BP. And Kevin’s idea of giving neutron representation of external-attachment-points (good idea), can be used in the implementation of Maruti’s BP where in the attachment-points can be fed to ‘net-gateway-create’ command, instead of giving physical-network switch names/ports. So we request Kevin , Racha and others, to peruse Maruti’s BP and post comments/questions on the same, more specifically from the resource representation perspective (REST APIs and CLIs). -- Thanks, Vivek From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Friday, November 14, 2014 10:17 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] L2 gateway as a service Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.commailto:igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.commailto:mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.commailto:maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at https://review.openstack.org/#/c/134179/ Thanks, Maruti ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Igor Duarte Cardoso. http://igordcard.com @igordcardhttps://twitter.com/igordcard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] L2 gateway as a service
Last Friday I recall we had two discussions around this topic. One in the morning, which I think led to Maruti to push [1]. The way I understood [1] was that it is an attempt at unifying [2] and [3], by choosing the API approach of one and the architectural approach of the other. [1] https://review.openstack.org/#/c/134179/ [2] https://review.openstack.org/#/c/100278/ [3] https://review.openstack.org/#/c/93613/ Then there was another discussion in the afternoon, but I am not 100% of the outcome. All this churn makes me believe that we probably just need to stop pretending we can achieve any sort of consensus on the approach and let the different alternatives develop independently, assumed they can all develop independently, and then let natural evolution take its course :) Ultimately the biggest debate is on what the API model needs to be for these abstractions. We can judge on which one is the best API of all, but sometimes this ends up being a religious fight. A good API for me might not be a good API for you, even though I strongly believe that a good API is one that can: - be hard to use incorrectly - clear to understand - does one thing, and one thing well So far I have been unable to be convinced why we'd need to cram more than one abstraction in one single API, as it does violate the above mentioned principles. Ultimately I like the L2 GW API proposed by 1 and 2 because it's in line with those principles. I'd rather start from there and iterate. My 2c, Armando On 14 November 2014 08:47, Salvatore Orlando sorla...@nicira.com wrote: Thanks guys. I think you've answered my initial question. Probably not in the way I was hoping it to be answered, but it's ok. So now we have potentially 4 different blueprint describing more or less overlapping use cases that we need to reconcile into one? If the above is correct, then I suggest we go back to the use case and make an effort to abstract a bit from thinking about how those use cases should be implemented. Salvatore On 14 November 2014 15:42, Igor Cardoso igordc...@gmail.com wrote: Hello all, Also, what about Kevin's https://review.openstack.org/#/c/87825/? One of its use cases is exactly the L2 gateway. These proposals could probably be inserted in a more generic work for moving existing datacenter L2 resources to Neutron. Cheers, On 14 November 2014 15:28, Mathieu Rohon mathieu.ro...@gmail.com wrote: Hi, As far as I understood last friday afternoon dicussions during the design summit, this use case is in the scope of another umbrella spec which would define external connectivity for neutron networks. Details of those connectivity would be defined through service plugin API. Ian do you plan to define such an umbrella spec? or at least, could you sum up the agreement of the design summit discussion in the ML? I see at least 3 specs which would be under such an umbrella spec : https://review.openstack.org/#/c/93329/ (BGPVPN) https://review.openstack.org/#/c/101043/ (Inter DC connectivity with VPN) https://review.openstack.org/#/c/134179/ (l2 gw aas) On Fri, Nov 14, 2014 at 1:13 PM, Salvatore Orlando sorla...@nicira.com wrote: Thanks Maruti, I have some comments and questions which I've posted on gerrit. There are two things I would like to discuss on the mailing list concerning this effort. 1) Is this spec replacing https://review.openstack.org/#/c/100278 and https://review.openstack.org/#/c/93613 - I hope so, otherwise this just adds even more complexity. 2) It sounds like you should be able to implement this service plugin in either a feature branch or a repository distinct from neutron. Can you confirm that? Salvatore On 13 November 2014 13:26, Kamat, Maruti Haridas maruti.ka...@hp.com wrote: Hi Friends, As discussed during the summit, I have uploaded the spec for review at https://review.openstack.org/#/c/134179/ Thanks, Maruti ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Igor Duarte Cardoso. http://igordcard.com @igordcard https://twitter.com/igordcard ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
