Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-13 Thread Stefano Maffulli
On 08/12/2014 06:46 PM, Wuhongning wrote: I couldn't have been at the IRC meeting for the time difference, are there any conclusion for this topic, or is it still open? I, the PTL, some core reviewers and many in the GBP team are actively working on a proposal to send to the list for quick

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-13 Thread Wuhongning
Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On 08/12/2014 06:46 PM, Wuhongning wrote: I couldn't have been at the IRC meeting for the time difference, are there any conclusion for this topic, or is it still open? I, the PTL, some core reviewers and many

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-12 Thread loy wolfe
Hi Paul, Below are some other useful GBP reference pages: https://wiki.opendaylight.org/view/Project_Proposals:Group_Based_Policy_Plugin http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html I think the root cause

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-12 Thread Sumit Naiksatam
Per the blueprint spec [1], what has been proposed are optional extensions which complement the existing Neutron core resources' model: The main advantage of the extensions described in this blueprint is that they allow for an application-centric interface to Neutron that complements the

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-11 Thread loy wolfe
Hi Sumit, First I want to say I'm not opposed to GBP itself, but has many confusion about it's core resource model and how it will integrate with neutron core. Do you mean for whatever GBP backend configured in any future Neutron deployment, so long as they are in tree, then ML2 core plugin

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-11 Thread CARVER, PAUL
loy wolfe [mailto:loywo...@gmail.com] wrote: Then since Network/Subnet/Port will never be treated just as LEGACY COMPATIBLE role, there is no need to extend Nova-Neutron interface to follow the GBP resource. Anyway, one of optional service plugins inside Neutron shouldn't has any impact on Nova

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-11 Thread Hemanth Ravi
On Fri, Aug 8, 2014 at 7:13 PM, Armando M. arma...@gmail.com wrote: On Fri, Aug 8, 2014 at 5:38 PM, Armando M. arma...@gmail.com wrote: One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done.

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
Can you link to the etherpad you mentioned? In the mean time, apologies for another analogy in advance. :-) If I give you an API to sort a list, I'm free to implement it however I want as long as I return a sorted list. However, there is no way me to know based on a call to this API that you

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Wuhongning
to accept. From: Kevin Benton [blak...@gmail.com] Sent: Friday, August 08, 2014 2:42 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward Can you link

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread CARVER, PAUL
Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make sense to move all advanced extension out of ML2, like security group, qos...? Then we can just talk about advanced service itself, without bothering basic neutron object (network/subnet/port) A modular layer 3 (ML3) analogous to ML2

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
The existing constructs will not change. On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com wrote: Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make sense to move all advanced extension out of ML2, like security group, qos...? Then we can just talk about advanced service itself,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Ivar Lazzaro
Hi Paul, Don't need to worry, you are perfectly right, GBP API is not replacing anything :). Also thanks for sharing your opinion on this matter. Thanks, Ivar. On Fri, Aug 8, 2014 at 5:46 PM, CARVER, PAUL pc2...@att.com wrote: Wuhongning [mailto:wuhongn...@huawei.com] wrote: Does it make

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Akash Gangil
Quick Question: From what I understand, GBP is a high level declarative way of configuring the network which ultimately gets mapped to basic Neutron API's via some business logic. Why can't it be in a module of it own? In that way users who want to use it can just install that and use it as an

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Jay Pipes
On 08/08/2014 08:55 AM, Kevin Benton wrote: The existing constructs will not change. A followup question on the above... If GPB API is merged into Neutron, the next logical steps (from what I can tell) will be to add drivers that handle policy-based payloads/requests. Some of these

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Ivar Lazzaro
Hi Jay, You can choose. The whole purpose of this is about flexibility, if you want to use GBP API 'only' with a specific driver you just can. Additionally, given the 'ML2 like' architecture, the reference mapping driver can ideally run alongside by filling the core Neutron constructs without

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Salvatore Orlando
It might be because of the wording used, but it seems to me that you're making it sound like the group policy effort could have been completely orthogonal to neutron as we know it now. What I understood is that the declarative abstraction offered by group policy could do without any existing

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron project. If someone uses the current APIs, the group policy plugin will make sure they don't violate any policy constraints before

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Sumit Naiksatam
Hi Jay, To extend Ivar's response here, the core resources and core plugin configuration does not change with the addition of these extensions. The mechanism to implement the GBP extensions is via a service plugin. So even in a deployment where a GBP service plugin is deployed with a driver which

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Jay Pipes
On 08/08/2014 12:29 PM, Sumit Naiksatam wrote: Hi Jay, To extend Ivar's response here, the core resources and core plugin configuration does not change with the addition of these extensions. The mechanism to implement the GBP extensions is via a service plugin. So even in a deployment where a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron project. If someone uses the current APIs, the group policy plugin

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Sumit Naiksatam
On Fri, Aug 8, 2014 at 12:45 PM, Armando M. arma...@gmail.com wrote: On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote: There is an enforcement component to the group policy that allows you to use the current APIs and it's the reason that group policy is integrated into the neutron

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Prasad Vellanki
GBP is about networking policy and hence limited to networking constructs. It enhances the networking constructs. Since it follows more or less the plugin model, it is not in one monolithic module but fans out to the policy module and is done via extension. On Fri, Aug 8, 2014 at 12:45 PM,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
Adding the GBP extension to Neutron does not change the nature of the software architecture of Neutron making it more or less monolithic. I agree with this statement...partially: the way GBP was developed is in accordance to the same principles and architectural choices made for the service

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Kevin Benton
This is the statement that makes me trip over, I don't know what that means. Does it mean that you are so incredibly shocked by the stupidity of that statement that you fall down? Or does it mean something else? Policy decision points can be decentralized from the system under scrutiny,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
On 8 August 2014 14:55, Kevin Benton blak...@gmail.com wrote: This is the statement that makes me trip over, I don't know what that means. Does it mean that you are so incredibly shocked by the stupidity of that statement that you fall down? Or does it mean something else? Why would you

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Prasad Vellanki
On Fri, Aug 8, 2014 at 2:21 PM, Armando M. arma...@gmail.com wrote: Adding the GBP extension to Neutron does not change the nature of the software architecture of Neutron making it more or less monolithic. I agree with this statement...partially: the way GBP was developed is in accordance

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done. It would be important in the policy type of framework to have such scoping The framework you're referring to is common and already

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Hemanth Ravi
On Fri, Aug 8, 2014 at 5:38 PM, Armando M. arma...@gmail.com wrote: One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done. It would be important in the policy type of framework to have such

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Armando M.
On Fri, Aug 8, 2014 at 5:38 PM, Armando M. arma...@gmail.com wrote: One advantage of the service plugin is that one can leverage the neutron common framework such as Keystone authentication where common scoping is done. It would be important in the policy type of framework to have such

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Kevin Benton
I mean't 'side stepping' why GBP allows for the comment you made previous, With the latter, a mapping driver could determine that communication between these two hosts can be prevented by using an ACL on a router or a switch, which doesn't violate the user's intent and buys a performance

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Aaron Rosen
On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton blak...@gmail.com wrote: I mean't 'side stepping' why GBP allows for the comment you made previous, With the latter, a mapping driver could determine that communication between these two hosts can be prevented by using an ACL on a router or a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Mohammad Banikazemi
Thierry Carrez thie...@openstack.org wrote on 08/07/2014 06:23:56 AM: From: Thierry Carrez thie...@openstack.org To: openstack-dev@lists.openstack.org Date: 08/07/2014 06:25 AM Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward Armando M. wrote

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Subrahmanyam Ongole
questions) Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On Aug 6, 2014, at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: However, it seems to me that the end-goal of the GBP effort is *actually* to provide a higher-layer API to Neutron that would

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Thierry Carrez
Armando M. wrote: This thread is moving so fast I can't keep up! The fact that troubles me is that I am unable to grasp how we move forward, which was the point of this thread to start with. It seems we have 2 options: - We make GBP to merge as is, in the Neutron tree, with some minor

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Nachi Ueno
Hi folks I think this thread is still mixing topics. I feel we can archive 1000 mails :P so let me name it and let me write my thought on this. [Topic1] Nova parity priority I do understand concern and this is highest priority. However, group based policy effort won't slower this effort.

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Aaron Rosen
Hi Kevin, I feel as your latest response is completely side stepping the points we have been trying to get to in the last series of emails. At the end of the day I don't believe we are changing the laws of networking (or perhaps we are?). Thus I think it's important to actually get down to the

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Kevin Benton
You said you had no idea what group based policy was buying us so I tried to illustrate what the difference between declarative and imperative network configuration looks like. That's the major selling point of GBP so I'm not sure how that's 'side stepping' any points. It removes the need for the

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-07 Thread Aaron Rosen
On Thu, Aug 7, 2014 at 9:54 AM, Kevin Benton blak...@gmail.com wrote: You said you had no idea what group based policy was buying us so I tried to illustrate what the difference between declarative and imperative network configuration looks like. That's the major selling point of GBP so I'm

[openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Stefano Santini
Hi, In my company (Vodafone), we (DC network architecture) are following very closely the work happening on Group Based Policy since we see a great value on the new paradigm to drive network configurations with an advanced logic. We're working on a new production project for an internal private

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 04:30 AM, Stefano Santini wrote: Hi, In my company (Vodafone), we (DC network architecture) are following very closely the work happening on Group Based Policy since we see a great value on the new paradigm to drive network configurations with an advanced logic. We're working on

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Hi, I've made my way through the group based policy code and blueprints and I'd like ask several questions about it. My first question really is what is the advantage that the new proposed group based policy model buys us? Bobs says, The group-based policy BP approved for Juno addresses the

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ryan Moats
Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM: [snip] AFAICT, there is nothing that can be done with the GBP API that cannot be done with the low-level regular Neutron API. I'll take you up on that, Jay :) How exactly do I specify behavior between two collections of ports

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Hi Aaron, These are good questions, but can we move this to a different thread labeled what is the point of group policy? I don't want to derail this one again and we should stick to Salvatore's options about the way to move forward with these code changes. On Aug 6, 2014 12:42 PM, Aaron Rosen

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Hi Ryan, On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote: Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM: [snip] AFAICT, there is nothing that can be done with the GBP API that cannot be done with the low-level regular Neutron API. I'll take you up

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Hi Kevin, I think we should keep these threads together as we need to understand the benefit collectively before we move forward with what to do. Aaron On Wed, Aug 6, 2014 at 12:03 PM, Kevin Benton blak...@gmail.com wrote: Hi Aaron, These are good questions, but can we move this to a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Salvatore Orlando
As long as the discussion stays focused on how group policies are beneficial for the user community and how the Neutron developer community should move forward, I reckon it's fine to keep the discussion in this thread. Salvatore Il 06/ago/2014 21:18 Aaron Rosen aaronoro...@gmail.com ha scritto:

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Hi Aaron, Please note that the user using the current reference implementation doesn't need to create Networks, Ports, or anything else. As a matter of fact, the mapping is done implicitly. Also, I agree with Kevin when he says that this is a whole different discussion. Thanks, Ivar. On Wed,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote: Hi Aaron, Please note that the user using the current reference implementation doesn't need to create Networks, Ports, or anything else. As a matter of fact, the mapping is done implicitly. The user still needs to

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
I believe the referential security group rules solve this problem (unless I'm not understanding): I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference implementation with the existing APIs. Under this light, it's not going to look

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ryan Moats
Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 02:12:05 PM: From: Aaron Rosen aaronoro...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/06/2014 02:12 PM Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
The translation to creating a network is what is being done implicitly. Another plugin could choose to implement this entirely using something like security groups on a single giant network. On Wed, Aug 6, 2014 at 1:38 PM, Aaron Rosen aaronoro...@gmail.com wrote: On Wed, Aug 6, 2014 at

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 03:46 PM, Kevin Benton wrote: I believe the referential security group rules solve this problem (unless I'm not understanding): I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference implementation with the existing

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote: I believe the referential security group rules solve this problem (unless I'm not understanding): I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
/2014 02:12 PM Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward Hi Ryan, On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats rmo...@us.ibm.com wrote: Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 01:04:41 PM: [snip] AFAICT, there is nothing

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote: I believe the referential security group rules solve this problem (unless I'm not understanding): I think the disconnect is that you are comparing the way to current mapping

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Mohammad Banikazemi
Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 04:09:20 PM: From: Jay Pipes jaypi...@gmail.com To: openstack-dev@lists.openstack.org Date: 08/06/2014 04:12 PM Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On 08/06/2014 03:46 PM, Kevin Benton

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Vendors swapping out components is only one possibility. Once people use this declarative model, optimizations can be made on the reference side as well. ACLs can be placed on L3 agents to reduce the rule count on individual compute nodes, etc. Everyone benefits from the abstraction, not just

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote: I believe the referential security group rules solve this problem (unless I'm not understanding): I

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Pedro Marques
On Aug 6, 2014, at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: However, it seems to me that the end-goal of the GBP effort is *actually* to provide a higher-layer API to Neutron that would essentially enable proprietary vendors to entirely swap out all of Neutron core for a new set of

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Prasad Vellanki
Jay Doesnt the current plugin model in neutron work the way you are saying. We have a a core set of APIs that there is a reference model for and individual vendors have substituted plugins that enhance and sometimes replace networking component. GBP in that respect does not change. There is a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 04:36 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote: I believe the referential security group rules solve this

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Wed, Aug 6, 2014 at 1:52 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/06/2014 04:36 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote: On 08/06/2014 04:13 PM, Sumit Naiksatam wrote: On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 04:51 PM, Prasad Vellanki wrote: Jay Doesnt the current plugin model in neutron work the way you are saying. We have a a core set of APIs that there is a reference model for and individual vendors have substituted plugins that enhance and sometimes replace networking component. GBP

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ryan Moats
[snipping to save BW] Aaron Rosen aaronoro...@gmail.com wrote on 08/06/2014 03:26:24 PM: Note: I'm not going to use the pure group policy API as I have been a fan of the 2-group approach from day 1, I'm going to use the commands as stated in the patch set, and I'm going to assume (dangerous

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Jay Pipes
On 08/06/2014 04:51 PM, Pedro Marques wrote: Neutron allows vendors to speak to proprietary device APIs, it was designed to do so, AFAIK. It is also possibly to entirely swap out all of the Neutron core... the proponents of the group based policy didn't have to go through so much trouble if that

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
In all seriousness, folks, I'm bringing up points about the proposed API because I see the current mess of Neutron integration with Nova, I see that nova-network has been undeprecated due to continuing lack of parity and HA concerns in Neutron, and I want things to be better, not worse. Again, I

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
+1 Kevin. I really fail to see how a patch which has been ready for a long time now is the worst enemy of Nova Parity. This is starting to feel kind of ad-hoc... On Aug 6, 2014 11:42 PM, Kevin Benton blak...@gmail.com wrote: In all seriousness, folks, I'm bringing up points about the proposed

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote: I believe the referential security group rules solve this problem (unless I'm not understanding): I think the disconnect is that you are comparing the way to current mapping driver implements things for the reference

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
By working at the port level you have already eliminated your ability to implement the filtering at different components of the network. They now need to be implemented in stateful rules at the port level and the device has to support security groups. On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Armando M.
This thread is moving so fast I can't keep up! The fact that troubles me is that I am unable to grasp how we move forward, which was the point of this thread to start with. It seems we have 2 options: - We make GBP to merge as is, in the Neutron tree, with some minor revision (e.g. naming?); -

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
I think we should merge it and just prefix the API for now with '/your_application_will_break_after_juno_if_you_use_this/' On Aug 6, 2014 4:41 PM, Armando M. arma...@gmail.com wrote: This thread is moving so fast I can't keep up! The fact that troubles me is that I am unable to grasp how we

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
I would reword that to: '/your_application_may_break_after_juno_if_you_use_this/' in the event of the possibility that it doesn't break. ;-) On Wed, Aug 6, 2014 at 3:47 PM, Kevin Benton blak...@gmail.com wrote: I think we should merge it and just prefix the API for now with

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Armando M.
On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote: I think we should merge it and just prefix the API for now with '/your_application_will_break_after_juno_if_you_use_this/' And you make your call based and what pros and cons exactly, If I am ask? Let me start: Option 1: - pros

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton blak...@gmail.com wrote: By working at the port level you have already eliminated your ability to implement the filtering at different components of the network. They now need to be implemented in stateful rules at the port level and the device has

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Salvatore Orlando
I was asked beforehand what I mean with * consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in this thread) and treat it accordingly The group based policies, although implemented as a service plugin, are quite different from the ones we have now. Things like firewall,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Given this information I don't see any reason why the backend system couldn't do enforcement at the logical router and if it did so neither parties would know. With security groups you are specifying that nothing can contact these devices on those ports unless they come from the allowed IP

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Pedro Marques
On Aug 6, 2014, at 3:56 PM, Armando M. arma...@gmail.com wrote: On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote: I think we should merge it and just prefix the API for now with '/your_application_will_break_after_juno_if_you_use_this/' And you make your call based and what

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote: Given this information I don't see any reason why the backend system couldn't do enforcement at the logical router and if it did so neither parties would know. With security groups you are specifying that nothing can

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Armando M.
This is probably not intentional from your part ,but your choice of words make it seem that you are deriding the efforts of the team behind this effort. While i may disagree technically here and there with their current design, it seems to me that the effort in question is rather broad based

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
That's the point. By using security groups, you are forcing a certain kind of enforcement that must be honored and might not be necessary if the original intent was just to isolate between groups. In the example you gave, it cannot be implemented on the router without violating the constraints of

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
[Moving my reply to the correct thread as someone changed the subject line.] On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote: Given this information I don't see any reason why the backend system couldn't do enforcement at the logical router and if it did so neither

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
[Moving my reply to the correct thread as someone changed the subject line. Attempt 2 :) ] On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote: Given this information I don't see any reason why the backend system couldn't do enforcement at the logical router and if it did so

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
[Moving my reply to the correct thread as someone changed the subject line. Attempt 3 :'( ] On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton blak...@gmail.com wrote: Given this information I don't see any reason why the backend system couldn't do enforcement at the logical router and if it did

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
Gah, clearly hitting some kind of gmail bug as i replied to the right thread all 3 times i believe. On Wed, Aug 6, 2014 at 4:56 PM, Aaron Rosen aaronoro...@gmail.com wrote: [Moving my reply to the correct thread as someone changed the subject line. Attempt 3 :'( ] On Wed, Aug 6, 2014 at

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Richard Woo
+1 On Aug 6, 2014 7:07 PM, Salvatore Orlando sorla...@nicira.com wrote: I was asked beforehand what I mean with * consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in this thread) and treat it accordingly The group based policies, although implemented as a service

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Ivar Lazzaro
Hi Pedro, I agree that having as much users/operators as possible using the API is the winner option. I think you should move this comment also in the main thread since it looks that the Subject has been accidentally modified. Cheers, Ivar. On Thu, Aug 7, 2014 at 1:28 AM, Pedro Marques

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton blak...@gmail.com wrote: That's the point. By using security groups, you are forcing a certain kind of enforcement that must be honored and might not be necessary if the original intent was just to isolate between groups. In the example you gave,

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Stefano Maffulli
On 08/06/2014 04:57 PM, Aaron Rosen wrote: Gah, clearly hitting some kind of gmail bug as i replied to the right thread all 3 times i believe. gmail is the new Outlook ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
I prefer merged because moving it to a separate project blocks it from enforcing policy on the current API (including calls between service plugins). On Wed, Aug 6, 2014 at 4:56 PM, Armando M. arma...@gmail.com wrote: On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote: I think we

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Hemanth Ravi
Hi, I agree that Option 1 would be best way to make the GBP API available to operators and to make forward progress with the API. Regards, -hemanth On Wed, Aug 6, 2014 at 5:04 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote: Hi Pedro, I agree that having as much users/operators as possible

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Web tier can communicate with anything except for the DB. App tier can only communicate with Web and DB. DB can communicate with App. These high-level constraints can then be implemented as security groups like you showed, or network hardware ACLs like I had shown. But if you start with the

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Prasad Vellanki
It seems like Option 1 would be preferable. User can use this right away. The code and to a large extent BP has gone through quite a bit of review already so it seems to me that there actually going lot less than usual. I dont see a whole of lot Con on this. Though there are still some issues

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Stephen Wong
Hi, Thanks to Armando for steering the discussion back to the original intent. On Wed, Aug 6, 2014 at 3:56 PM, Armando M. arma...@gmail.com wrote: On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote: I think we should merge it and just prefix the API for now with

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Armando M.
On 6 August 2014 17:34, Prasad Vellanki prasad.vella...@oneconvergence.com wrote: It seems like Option 1 would be preferable. User can use this right away. People choosing Option 1 may think that the shortest route may be the best, that said the drawback I identified is not to be dismissed

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
I think this could be another reason why people associated GBP and nova-network parity in this thread: the fact that new abstractions are introduced without solidifying the foundations of the project is a risk to GBP as well as Neutron itself. How does a separate project fix this? It seems to me

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote: Web tier can communicate with anything except for the DB. App tier can only communicate with Web and DB. DB can communicate with App. These high-level constraints can then be implemented as security groups like you

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Rudra Rugge
On Wed, Aug 6, 2014 at 6:40 PM, Aaron Rosen aaronoro...@gmail.com wrote: On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton blak...@gmail.com wrote: Web tier can communicate with anything except for the DB. App tier can only communicate with Web and DB. DB can communicate with App. These

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Prasad Vellanki
I don't think people are choosing because of the shortest route but rather these may be two different items that are not completely exclusive but different enough. Nova parity addresses the scope to have existing well understood and stable api currently supported in nova to be supported in neutron

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Kevin Benton
Do you not see a difference between explicitly configuring networks, a router and FWaaS rules with logging and just stating that two groups of servers can only communicate via one TCP port with all connections logged? The first is very prone to errors for someone deploying an application without a

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Alan Kavanagh
Message- From: Pedro Marques [mailto:pedro.r.marq...@gmail.com] Sent: August-06-14 4:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward On Aug 6, 2014, at 1:27 PM, Jay Pipes jaypi

  1   2   >