nstack.org
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
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 eva
alone component, or as an integral part of HEAT or
Congress.
From: Sumit Naiksatam [sumitnaiksa...@gmail.com]
Sent: Wednesday, August 13, 2014 12:18 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Fwd: FW: [Neutro
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 existin
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 o
On Fri, Aug 8, 2014 at 7:13 PM, Armando M. wrote:
>
>> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. 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
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 Nov
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 shall
>
>
> On Fri, Aug 8, 2014 at 5:38 PM, Armando M. 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 su
On Fri, Aug 8, 2014 at 5:38 PM, Armando M. 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
>> scoping
>>
> 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 reus
On Fri, Aug 8, 2014 at 2:21 PM, Armando M. 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 to the same
On 8 August 2014 14:55, Kevin Benton 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 think that? I
>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,
Unfor
>
> 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
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, Arman
On Fri, Aug 8, 2014 at 12:45 PM, Armando M. wrote:
> On 8 August 2014 10:56, Kevin Benton 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
On 8 August 2014 10:56, Kevin Benton 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 will make sure
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 GBP
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 i
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 passi
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 neutr
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 ever
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 drivers,
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 int
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 wrote:
> Wuhongning [mailto:wuhongn...@huawei.com] wrote:
>
> >Does it make sense to mo
The existing constructs will not change.
On Aug 8, 2014 9:49 AM, "CARVER, PAUL" 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,
> wit
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
dusers 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 li
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 migh
Thierry Carrez wrote on 08/07/2014 06:23:56 AM:
> From: Thierry Carrez
> 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:
> > This threa
On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton 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 switch, which do
>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
improvem
On Thu, Aug 7, 2014 at 9:54 AM, Kevin Benton 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 not sure how th
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 u
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 ne
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.
Bec
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 min
; 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 wrote:
> >
> > However, it seems to me that the end-goal of th
/Alan
-Original 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
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
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
On Wed, Aug 6, 2014 at 6:40 PM, Aaron Rosen wrote:
>
> On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton 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
On Wed, Aug 6, 2014 at 5:27 PM, Kevin Benton 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 showed, or network
>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
On 6 August 2014 17:34, Prasad Vellanki
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 either (and I am
sure there many m
Hi,
Thanks to Armando for steering the discussion back to the original
intent.
On Wed, Aug 6, 2014 at 3:56 PM, Armando M. wrote:
>
> On 6 August 2014 15:47, Kevin Benton wrote:
>
>> I think we should merge it and just prefix the API for now with
>> '/your_application_will_break_after_juno
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
wit
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 securi
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 wrote:
> Hi Pedro,
>
> I agree that having as much users/operators as possible using the API is
> th
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. wrote:
>
> On 6 August 2014 15:47, Kevin Benton wrote:
>
>> I think we should merge it and just prefi
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
http://lists.op
On Wed, Aug 6, 2014 at 4:46 PM, Kevin Benton 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, it cannot be im
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
wrote:
+1
On Aug 6, 2014 7:07 PM, "Salvatore Orlando" 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 plugin, are
>
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 wrote:
> [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 Be
[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 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
> par
[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 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
> parti
[Moving my reply to the correct thread as someone changed the subject line.]
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton 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.
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 t
>
> 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 ba
On Wed, Aug 6, 2014 at 4:18 PM, Kevin Benton 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 contact these
> d
On Aug 6, 2014, at 3:56 PM, Armando M. wrote:
>
> On 6 August 2014 15:47, Kevin Benton 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
>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 addres
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, lo
On Wed, Aug 6, 2014 at 3:35 PM, Kevin Benton 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 to support se
On 6 August 2014 15:47, Kevin Benton 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
- immediat
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 wrote:
> I think we should merge it and just prefix the API for now with
> '/your_application_will_break_afte
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." 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
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?);
- We
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
On Wed, Aug 6, 2014 at 12: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 w
+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" wrote:
> >In all seriousness, folks, I'm bringing up points about the proposed API
> because I
>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,
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 tha
[snipping to save BW]
Aaron Rosen 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 I know) that I
>
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
On Wed, Aug 6, 2014 at 1:52 PM, Jay Pipes wrote:
> On 08/06/2014 04:36 PM, Sumit Naiksatam wrote:
>>
>> On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes wrote:
>>>
>>> On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote:
>>
>>
>>
On 08/06/2014 04:36 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes wrote:
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote:
I believe the referential security group rules solve this problem
(unless
I'm not understandin
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 refer
On Aug 6, 2014, at 1:27 PM, Jay Pipes 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
> drivers that sp
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes wrote:
> On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
>>
>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton wrote:
I believe the referential security group rules solve this problem
(unless
I'm not understanding):
>>>
>>>
>>> I think th
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 hardw
Jay Pipes wrote on 08/06/2014 04:09:20 PM:
> From: Jay Pipes
> 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 wrote
On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:
On Wed, Aug 6, 2014 at 12: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 t
On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats wrote:
> Aaron Rosen wrote on 08/06/2014 02:12:05 PM:
>
> > From: Aaron Rosen
>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> >
> > Date: 08/06/2014 02:12 PM
> > Subject: R
On Wed, Aug 6, 2014 at 12: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 wi
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
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 wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro
Aaron Rosen wrote on 08/06/2014 02:12:05 PM:
> From: Aaron Rosen
> To: "OpenStack Development Mailing List (not for usage questions)"
>
> Date: 08/06/2014 02:12 PM
> Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
> and the way forward
>
>
>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
On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro 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 create an endpoi
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, A
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" ha scritto:
> Hi Kevin,
>
> I th
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 wrote:
> Hi Aaron,
>
> These are good questions, but can we move this to a different thread
> l
Hi Ryan,
On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats wrote:
> Jay Pipes 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 ex
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
Jay Pipes 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 residing
in the sa
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
>
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 a
1 - 100 of 101 matches
Mail list logo