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
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
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
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
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
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
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.
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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:
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,
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
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
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
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
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
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
/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
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
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
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
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
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
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
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
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
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
[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
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
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
+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
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
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
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?);
-
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
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
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
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
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,
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
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
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
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
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
[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
[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
[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
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
+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
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
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,
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
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
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
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
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
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 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
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
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
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
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
98 matches
Mail list logo
