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 evaluation. Stay tuned.


 I've tried
 to collect main concerns from previous posts (if something is lost or
 mistaken, just let me know):
 
 Concern 1 [...] Concern 6 [...]

These are some of the concerns I saw, too. There are other, once you
start looking at this discussion as one touching the larger issue of how
we can, as a community, strike an acceptable balance between shipping
quality code while adding features, keeping the fast innovation pace.

 Is it an option to split the GBP into core and extension, to easily
 meet all those concerns? 
[...]

I think these are all valid suggestions and they are in similar forms on
the table at the moment as options.

The solution we're looking for is not something that is limited to GBP
but a wider fix (or at least a reasonable attempt) to the balancing act
I mentioned above: new features vs 'stable' code. Expect a proposal soon.

/stef


-- 
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Wuhongning
Thanks for your reply, Stefano. 
Indeed general balancing issue are much more important than this special GBP 
case, and I'll stay tuned for your result.

However, what I want to touch here is another kind of balancing: how to 
introduce a huge feature(like GBP) into openstack, especially it already has 
its own resource model with some overlapping semantically? Even GBP code and 
API is stable enough and could be merged someday, this issue wouldn't disappear.

We may choose to push the whole big monolithic feature into one place, or 
decouple it into different layers, and merge each to corresponding layer: low 
level atomic layer like nova/neutron/cinder, and abstract level orchestration 
layer like heat/congress)


From: Stefano Maffulli [stef...@openstack.org]
Sent: Thursday, August 14, 2014 7:18 AM
To: openstack-dev@lists.openstack.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 reviewers and many in the GBP team are actively
working on a proposal to send to the list for quick evaluation. Stay tuned.


 I've tried
 to collect main concerns from previous posts (if something is lost or
 mistaken, just let me know):

 Concern 1 [...] Concern 6 [...]

These are some of the concerns I saw, too. There are other, once you
start looking at this discussion as one touching the larger issue of how
we can, as a community, strike an acceptable balance between shipping
quality code while adding features, keeping the fast innovation pace.

 Is it an option to split the GBP into core and extension, to easily
 meet all those concerns?
[...]

I think these are all valid suggestions and they are in similar forms on
the table at the moment as options.

The solution we're looking for is not something that is limited to GBP
but a wider fix (or at least a reasonable attempt) to the balancing act
I mentioned above: new features vs 'stable' code. Expect a proposal soon.

/stef


--
Ask and answer questions on https://ask.openstack.org

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 of this long argument, is that GBP core model was
not designed native for Neutron, and they are introduced into Neutron so
radically, without careful tailoring and adaption. Maybe the GBP team also
don't want to do so, their intention is to maintain a unified model across
all kinds of platform including Neutron, Opendaylight, ACI/Opflex, etc.

However, redundancy and duplication exists between EP/EPG/BD/RD and
Port/Network/Subnet. So mapping is used between these objects, and I think
this is why so many voice to request moving GBP out and on top of Neutron.

Will GBP simply be an *addition*? It absolutely COULD be, but objectively
speaking, it's core model also allow it to BE-ABLE-TO take over Neutron
core resource (see the wiki above). GBP mapping spec suggested a nova -nic
extension to handle EP/EPG resource directly, thus all original Neutron
core resource can be shadowed away from user interface: GBP became the new
openstack network API :-) However no one can say depreciate Neutron core
here and now, but shall we leave Neutron core just as *traditional/legacy*?

Personally I prefer not to throw NW-Policy out of Neutron, but at the
perquisite that its core model should be reviewed and tailored. A new
lightweight model carefully designed native for Neutron is needed, but not
directly copying a whole bunch of monolithic core resource from existing
other system.

Here is the very basic suggestion: because core value of GBP is policy
template with contracts , throw away EP/EPG/L2P/L3P model while not just
renaming them again and again. APPLY policy template to existing Neutron
core resource, but not reinvent similar concept in GBP and then do the
mapping.


On Mon, Aug 11, 2014 at 9:12 PM, CARVER, PAUL pc2...@att.com wrote:

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 side.



 This gets to the root of why I was getting confused about Jay and others

 having Nova related concerns. I was/am assuming that GBP is simply an

 *additional* mechanism for manipulating Neutron, not a deprecation of any

 part of the existing Neutron API. I think Jay's concern and the reason

 why he keeps mentioning Nova as the biggest and most important consumer

 of Neutron's API stems from an assumption that Nova would need to change

 to use the GBP API.





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 existing network-centric interface.


It has been pointed out earlier in this thread that this is not a
replacement for the current Neutron core resources/API.

[1] 
https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm

On Tue, Aug 12, 2014 at 1:22 AM, loy wolfe loywo...@gmail.com wrote:
 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 of this long argument, is that GBP core model was not
 designed native for Neutron, and they are introduced into Neutron so
 radically, without careful tailoring and adaption. Maybe the GBP team also
 don't want to do so, their intention is to maintain a unified model across
 all kinds of platform including Neutron, Opendaylight, ACI/Opflex, etc.

 However, redundancy and duplication exists between EP/EPG/BD/RD and
 Port/Network/Subnet. So mapping is used between these objects, and I think
 this is why so many voice to request moving GBP out and on top of Neutron.

 Will GBP simply be an *addition*? It absolutely COULD be, but objectively
 speaking, it's core model also allow it to BE-ABLE-TO take over Neutron core
 resource (see the wiki above). GBP mapping spec suggested a nova -nic
 extension to handle EP/EPG resource directly, thus all original Neutron core
 resource can be shadowed away from user interface: GBP became the new
 openstack network API :-) However no one can say depreciate Neutron core
 here and now, but shall we leave Neutron core just as *traditional/legacy*?

 Personally I prefer not to throw NW-Policy out of Neutron, but at the
 perquisite that its core model should be reviewed and tailored. A new
 lightweight model carefully designed native for Neutron is needed, but not
 directly copying a whole bunch of monolithic core resource from existing
 other system.

 Here is the very basic suggestion: because core value of GBP is policy
 template with contracts , throw away EP/EPG/L2P/L3P model while not just
 renaming them again and again. APPLY policy template to existing Neutron
 core resource, but not reinvent similar concept in GBP and then do the
 mapping.


 On Mon, Aug 11, 2014 at 9:12 PM, CARVER, PAUL pc2...@att.com wrote:

 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 side.



 This gets to the root of why I was getting confused about Jay and others

 having Nova related concerns. I was/am assuming that GBP is simply an

 *additional* mechanism for manipulating Neutron, not a deprecation of any

 part of the existing Neutron API. I think Jay's concern and the reason

 why he keeps mentioning Nova as the biggest and most important consumer

 of Neutron's API stems from an assumption that Nova would need to change

 to use the GBP API.





 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 shall always
be there to expose the Neutron core resource: Network/Subnet/Port?

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 side.

If we agree on this point, core model of GBP should be reviewed, but not
just focus on naming convention whether it should be called EP or policy
target, then leaving some words here to emphasize GBP is only
complementary. In fact, EP/EPG/BD/RD has been designed to be ABLE TO
REPLACE Neutron core resource, with mapping as the first step to keep
compatible.

In fact, if Neutron core source shall never to be swapped out, GBP core
object could be greatly simplified, because mapping already means
redundancy :-) Only policy-group is meaningful, behind which are very
important policy concept: consumer/producer contracts. After PG is defined,
it should be directly applied to existing Neutron core resource, but not
create similar concept of EP/L2P/L3P, then mapping to them. Mapping is
redundant, and I can understand it's necessity only if someday those
neutron core resource are planned to be swapped out.

Simple conclusion: if GBP is just an optional complementary, then after
defining policy template, directly APPLYING, but not create similar
redundant resource and then MAPPING it to existing neutron core resource.


On Sat, Aug 9, 2014 at 3:35 AM, Jay Pipes jaypi...@gmail.com wrote:

 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 service plugin is
 deployed with a driver which interfaces with a backend that perhaps
 directly understands some of the GBP constructs, that system would
 still need to have a core plugin configured that honors Neutron's core
 resources. Hence my earlier comment that GBP extensions are
 complementary to the existing core resources (in much the same way as
 the existing extensions in Neutron).


 OK, thanks Sumit. That clearly explains things for me.

 Best,
 -jay



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 side.

This gets to the root of why I was getting confused about Jay and others
having Nova related concerns. I was/am assuming that GBP is simply an
*additional* mechanism for manipulating Neutron, not a deprecation of any
part of the existing Neutron API. I think Jay's concern and the reason
why he keeps mentioning Nova as the biggest and most important consumer
of Neutron's API stems from an assumption that Nova would need to change
to use the GBP API.

If I've understood the follow on discussions correctly, there's no need for
Nova to use the GBP API at all until/unless the Nova developers see benefit
in it because they can continue to accomplish everything with the existing
API. The GBP API simply provides a more application centric rather than
network centric representation of the same thing.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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. It would be important in the policy type of framework to
 have such scoping


 The framework you're referring to is common and already reusable, it's
 not a prerogative of Neutron.


  Are you suggesting that Service Plugins, L3, IPAM etc become individual
 endpoints, resulting in redundant authentication round-trips for each of
 the components.

 Wouldn't this result in degraded performance and potential consistency
 issues?


 The endpoint - in the OpenStack lingo - that exposes the API abstractions
 (concepts and operations) can be, logically and physically, different from
 the worker that implements these abstractions; authentication is orthogonal
 to this and I am not suggesting what you mention.


From what I understand, you are saying that the implementation could be
done via a mechanism different than a service plugin. Would this be done by
implementing the service plugin as a different process? This would imply
making changes to the the neutron server - plugin interface. If this is the
case, wouldn't it be better to use the existing mechanism to avoid
introducing any instability at this stage of the Juno cycle.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 might only be looking for the second
largest element, so it won't be the most efficient approach because I will
always have to sort the entire list.
If I give you a higher level API to declare that you want elements of a
list that match a criteria in a certain order, then the API can make the
optimization to not actually sort the whole list if you just need the first
of the largest two elements.

The former is analogous to the security groups API, and the latter to the
GBP API.
On Aug 7, 2014 4:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 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 switch, which doesn't violate the user's intent and buys a
 performance improvement and works with ports that don't support security
 groups..

 Neutron's current API is a logical abstraction and enforcement can be
 done however one chooses to implement it. I'm really trying to understand
 at the network level why GBP allows for these optimizations and performance
 improvements you talked about.

 You absolutely cannot enforce security groups on a firewall/router that
 sits at the boundary between networks. If you try, you are lying to the
 end-user because it's not enforced at the port level. The current neutron
 APIs force you to decide where things like that are implemented.


 The current neutron API's are just logical abstractions. Where and how
 things are actually enforced are 100% an implementation detail of a vendors
 system.  Anyways, moving the discussion to the etherpad...



 The higher level abstractions give you the freedom to move the
 enforcement by allowing the expression of broad connectivity requirements.

 Why are you bringing up logging connections?

 This was brought up as a feature proposal to FWaaS because this is a
 basic firewall feature missing from OpenStack. However, this does not
 preclude a FWaaS vendor from logging.

 Personally, I think one could easily write up a very short document
 probably less than one page with examples showing/exampling how the current
 neutron API works even without a much networking background.

 The difficulty of the API for establishing basic connectivity isn't
 really the problem. It's when you have to compose a bunch of requirements
 and make sure nothing is violating auditing and connectivity constraints
 that it becomes a problem. We are arguing about the levels of abstraction.
 You could also write up a short document explaining to novice programmers
 how to use C to read and write database entries to an sqlite database, but
 that doesn't mean it's the best level of abstraction for what the users are
 trying to accomplish.

 I'll let someone else explain the current GBP API because I'm not working
 on that. I'm just trying to convince you of the value of declarative
 network configuration.


 On Thu, Aug 7, 2014 at 12:02 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 not sure how that's 'side stepping' any points. It removes the need for
 the user to pick between implementation details like security
 groups/FWaaS/ACLs.


 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 improvement and works with ports that don't support security
 groups..

 Neutron's current API is a logical abstraction and enforcement can be
 done however one chooses to implement it. I'm really trying to understand
 at the network level why GBP allows for these optimizations and performance
 improvements you talked about.



 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts?

 It's one thing to understand the ports an application leverages and
 another to understand the differences between configuring VM firewalls,
 security groups, FWaaS, and router ACLs.


 Sure, but how does group based policy solve this. Security Groups and
 FWaaS are just different places of 

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

2014-08-08 Thread Wuhongning
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)

Traditionally, SG is applied in CN, and FWaas is applied in NN (bound to L3 
agent), however in DVR they are bluing, for each host has a L3 agent, this 
brings opportunity to move all service related features out of L2 agent, and 
coordinate  the two security modules (SG  FW for W-E traffic). However, 
neutron agents (l2/l3/advanced service) needs some rework.

When all these service features is detached from ML2, we can easily keep the 
mainstream OVS continually as L2 backend, and vendor specific hardware as the 
service policy enforcement backend such as acl/qos for high performance.

So maybe a trade-off is better: an optionally new policy service plugin 
together with SG and FWaas, cloud operate can choose what to present to 
enduser, but without concept of EP/EPG/BD/RD(now renamed to L2Pand L3P), Policy 
only focus on service layer, and policy template will be applied to existing 
neutron port object.

EP/EPG/L2P/L3P is really not so friendly to endusers facing. I asked some SMB 
IT staff and personal user of amazon AWS (they all have very limited networking 
knowledge), they can easily understand port/network/subnet, but can't 
understand those GBP objects. So, maybe apply advanced service policy to 
existing basic neutron object is more smoothly for endusers 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 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 might only be looking for the second largest element, 
so it won't be the most efficient approach because I will always have to sort 
the entire list.
If I give you a higher level API to declare that you want elements of a list 
that match a criteria in a certain order, then the API can make the 
optimization to not actually sort the whole list if you just need the first of 
the largest two elements.

The former is analogous to the security groups API, and the latter to the GBP 
API.

On Aug 7, 2014 4:00 PM, Aaron Rosen 
aaronoro...@gmail.commailto:aaronoro...@gmail.com wrote:



On Thu, Aug 7, 2014 at 12:08 PM, Kevin Benton 
blak...@gmail.commailto: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 switch, 
which doesn't violate the user's intent and buys a performance improvement and 
works with ports that don't support security groups..

Neutron's current API is a logical abstraction and enforcement can be done 
however one chooses to implement it. I'm really trying to understand at the 
network level why GBP allows for these optimizations and performance 
improvements you talked about.

You absolutely cannot enforce security groups on a firewall/router that sits at 
the boundary between networks. If you try, you are lying to the end-user 
because it's not enforced at the port level. The current neutron APIs force you 
to decide where things like that are implemented.

The current neutron API's are just logical abstractions. Where and how things 
are actually enforced are 100% an implementation detail of a vendors system.  
Anyways, moving the discussion to the etherpad...

The higher level abstractions give you the freedom to move the enforcement by 
allowing the expression of broad connectivity requirements.
Why are you bringing up logging connections?

This was brought up as a feature proposal to FWaaS because this is a basic 
firewall feature missing from OpenStack. However, this does not preclude a 
FWaaS vendor from logging.

Personally, I think one could easily write up a very short document probably 
less than one page with examples showing/exampling how the current neutron API 
works even without a much networking background.

The difficulty of the API for establishing basic connectivity isn't really the 
problem. It's when you have to compose a bunch of requirements and make sure 
nothing is violating auditing and connectivity constraints that it becomes a 
problem. We are arguing about the levels of abstraction. You could also write 
up a short document explaining to novice programmers how to use C to read and 
write database entries to an sqlite database, but that doesn't mean it's the 
best level of abstraction for what the users are trying to accomplish.

I'll let

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 sounds like a good idea. I still
think it's too late in the game to be shooting down all the work that the
GBP team has put in unless there's a really clean and effective way of
running AND iterating on GBP in conjunction with Neutron without being
part of the Juno release. As far as I can tell they've worked really
hard to follow the process and accommodate input. They shouldn't have
to wait multiple more releases on a hypothetical refactoring of how L3+ vs
L2 is structured.

But, just so I'm not making a horrible mistake, can someone reassure me
that GBP isn't removing the constructs of network/subnet/port from Neutron?

I'm under the impression that GBP is adding a higher level abstraction
but that it's not ripping basic constructs like network/subnet/port out
of the existing API. If I'm wrong about that I'll have to change my
opinion. We need those fundamental networking constructs to be present
and accessible to users that want/need to deal with them. I'm viewing
GBP as just a higher level abstraction over the top.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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,
 without
 bothering basic neutron object (network/subnet/port)

 A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I still
 think it's too late in the game to be shooting down all the work that the
 GBP team has put in unless there's a really clean and effective way of
 running AND iterating on GBP in conjunction with Neutron without being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure me
 that GBP isn't removing the constructs of network/subnet/port from Neutron?

 I'm under the impression that GBP is adding a higher level abstraction
 but that it's not ripping basic constructs like network/subnet/port out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 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 sounds like a good idea. I still
 think it's too late in the game to be shooting down all the work that the
 GBP team has put in unless there's a really clean and effective way of
 running AND iterating on GBP in conjunction with Neutron without being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure me
 that GBP isn't removing the constructs of network/subnet/port from Neutron?

 I'm under the impression that GBP is adding a higher level abstraction
 but that it's not ripping basic constructs like network/subnet/port out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 interface to
interact with Neutron while the rest continue with their lives as usual.




On Fri, Aug 8, 2014 at 9:25 PM, Kevin Benton blak...@gmail.com wrote:

 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,
 without
 bothering basic neutron object (network/subnet/port)

 A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I still
 think it's too late in the game to be shooting down all the work that the
 GBP team has put in unless there's a really clean and effective way of
 running AND iterating on GBP in conjunction with Neutron without being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?

 I'm under the impression that GBP is adding a higher level abstraction
 but that it's not ripping basic constructs like network/subnet/port out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Akash
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 drivers, AFAICT, will *not* be deconstructing these policy 
requests into the low-level port, network, and subnet 
creation/attachment/detachment commands, but instead will be calling out 
as-is to hardware that speaks the higher-level abstraction API [1], not 
the lower-level port/subnet/network APIs. The low-level APIs would 
essentially be consumed entirely within the policy-based driver, which 
would effectively mean that the only way a system would be able to 
orchestrate networking in systems using these drivers would be via the 
high-level policy API.


Is that correct? Very sorry if I haven't explained clearly my 
question... this is a tough question to frame eloquently :(


Thanks,
-jay

[1] 
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html



On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
mailto:pc2...@att.com wrote:

Wuhongning [mailto:wuhongn...@huawei.com
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 sounds like a good idea. I
still
think it's too late in the game to be shooting down all the work
that the
GBP team has put in unless there's a really clean and effective way of
running AND iterating on GBP in conjunction with Neutron without being
part of the Juno release. As far as I can tell they've worked really
hard to follow the process and accommodate input. They shouldn't have
to wait multiple more releases on a hypothetical refactoring of how
L3+ vs
L2 is structured.

But, just so I'm not making a horrible mistake, can someone reassure me
that GBP isn't removing the constructs of network/subnet/port from
Neutron?

I'm under the impression that GBP is adding a higher level abstraction
but that it's not ripping basic constructs like network/subnet/port out
of the existing API. If I'm wrong about that I'll have to change my
opinion. We need those fundamental networking constructs to be present
and accessible to users that want/need to deal with them. I'm viewing
GBP as just a higher level abstraction over the top.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 ever 'disturbing' your own driver (I'm not entirely sure about this
but it seems feasible).

I hope this answers your question,
Ivar.


On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:

 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, AFAICT, will *not* be deconstructing these policy
 requests into the low-level port, network, and subnet
 creation/attachment/detachment commands, but instead will be calling out
 as-is to hardware that speaks the higher-level abstraction API [1], not the
 lower-level port/subnet/network APIs. The low-level APIs would essentially
 be consumed entirely within the policy-based driver, which would
 effectively mean that the only way a system would be able to orchestrate
 networking in systems using these drivers would be via the high-level
 policy API.

 Is that correct? Very sorry if I haven't explained clearly my question...
 this is a tough question to frame eloquently :(

 Thanks,
 -jay

 [1] http://www.cisco.com/c/en/us/solutions/data-center-
 virtualization/application-centric-infrastructure/index.html

  On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 Wuhongning [mailto:wuhongn...@huawei.com
 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 sounds like a good idea. I
 still
 think it's too late in the game to be shooting down all the work
 that the
 GBP team has put in unless there's a really clean and effective way of
 running AND iterating on GBP in conjunction with Neutron without being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how
 L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure
 me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?

 I'm under the impression that GBP is adding a higher level abstraction
 but that it's not ripping basic constructs like network/subnet/port
 out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 neutron entity leveraging native
drivers, but can actually be used also with existing neutron plugins
through the mapping driver - which will provide a sort of backward
compatibility. And still in that case I'm not sure one would be able to use
traditional neutron API (or legacy as it has been called), since I
don't know if the mapping driver is bidirectional.

I know this probably stems from my ignorance on the subject - I had
unfortunately very little time to catch-up with this effort in the past
months.

Salvatore

On 8 August 2014 18:49, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 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 'disturbing' your own driver (I'm not entirely sure about this
 but it seems feasible).

 I hope this answers your question,
 Ivar.


 On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:

 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, AFAICT, will *not* be deconstructing these policy
 requests into the low-level port, network, and subnet
 creation/attachment/detachment commands, but instead will be calling out
 as-is to hardware that speaks the higher-level abstraction API [1], not the
 lower-level port/subnet/network APIs. The low-level APIs would essentially
 be consumed entirely within the policy-based driver, which would
 effectively mean that the only way a system would be able to orchestrate
 networking in systems using these drivers would be via the high-level
 policy API.

 Is that correct? Very sorry if I haven't explained clearly my question...
 this is a tough question to frame eloquently :(

 Thanks,
 -jay

 [1] http://www.cisco.com/c/en/us/solutions/data-center-
 virtualization/application-centric-infrastructure/index.html

  On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 Wuhongning [mailto:wuhongn...@huawei.com
 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 sounds like a good idea. I
 still
 think it's too late in the game to be shooting down all the work
 that the
 GBP team has put in unless there's a really clean and effective way
 of
 running AND iterating on GBP in conjunction with Neutron without
 being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how
 L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure
 me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?

 I'm under the impression that GBP is adding a higher level
 abstraction
 but that it's not ripping basic constructs like network/subnet/port
 out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be
 present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list

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 passing the request into the regular core/service plugins.


On Fri, Aug 8, 2014 at 11:02 AM, Salvatore Orlando sorla...@nicira.com
wrote:

 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 neutron entity leveraging native
 drivers, but can actually be used also with existing neutron plugins
 through the mapping driver - which will provide a sort of backward
 compatibility. And still in that case I'm not sure one would be able to use
 traditional neutron API (or legacy as it has been called), since I
 don't know if the mapping driver is bidirectional.

 I know this probably stems from my ignorance on the subject - I had
 unfortunately very little time to catch-up with this effort in the past
 months.

 Salvatore


 On 8 August 2014 18:49, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 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 'disturbing' your own driver (I'm not entirely sure about this
 but it seems feasible).

 I hope this answers your question,
 Ivar.


 On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:

 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, AFAICT, will *not* be deconstructing these policy
 requests into the low-level port, network, and subnet
 creation/attachment/detachment commands, but instead will be calling out
 as-is to hardware that speaks the higher-level abstraction API [1], not the
 lower-level port/subnet/network APIs. The low-level APIs would essentially
 be consumed entirely within the policy-based driver, which would
 effectively mean that the only way a system would be able to orchestrate
 networking in systems using these drivers would be via the high-level
 policy API.

 Is that correct? Very sorry if I haven't explained clearly my
 question... this is a tough question to frame eloquently :(

 Thanks,
 -jay

 [1] http://www.cisco.com/c/en/us/solutions/data-center-
 virtualization/application-centric-infrastructure/index.html

  On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 Wuhongning [mailto:wuhongn...@huawei.com
 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 sounds like a good idea. I
 still
 think it's too late in the game to be shooting down all the work
 that the
 GBP team has put in unless there's a really clean and effective way
 of
 running AND iterating on GBP in conjunction with Neutron without
 being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't
 have
 to wait multiple more releases on a hypothetical refactoring of how
 L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone
 reassure me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?

 I'm under the impression that GBP is adding a higher level
 abstraction
 but that it's not ripping basic constructs like network/subnet/port
 out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be
 present
 and accessible to users that want/need to deal with them. I'm
 viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 

Re: [openstack-dev] 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 interfaces with a backend that perhaps
directly understands some of the GBP constructs, that system would
still need to have a core plugin configured that honors Neutron's core
resources. Hence my earlier comment that GBP extensions are
complementary to the existing core resources (in much the same way as
the existing extensions in Neutron).

Thanks,
~Sumit.

On Fri, Aug 8, 2014 at 9:49 AM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 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 'disturbing' your own driver (I'm not entirely sure about this
 but it seems feasible).

 I hope this answers your question,
 Ivar.


 On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:

 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, AFAICT, will *not* be deconstructing these policy
 requests into the low-level port, network, and subnet
 creation/attachment/detachment commands, but instead will be calling out
 as-is to hardware that speaks the higher-level abstraction API [1], not the
 lower-level port/subnet/network APIs. The low-level APIs would essentially
 be consumed entirely within the policy-based driver, which would effectively
 mean that the only way a system would be able to orchestrate networking in
 systems using these drivers would be via the high-level policy API.

 Is that correct? Very sorry if I haven't explained clearly my question...
 this is a tough question to frame eloquently :(

 Thanks,
 -jay

 [1]
 http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html

 On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 Wuhongning [mailto:wuhongn...@huawei.com
 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 sounds like a good idea. I
 still
 think it's too late in the game to be shooting down all the work
 that the
 GBP team has put in unless there's a really clean and effective way
 of
 running AND iterating on GBP in conjunction with Neutron without
 being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how
 L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure
 me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?

 I'm under the impression that GBP is adding a higher level
 abstraction
 but that it's not ripping basic constructs like network/subnet/port
 out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be
 present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 GBP service plugin is
deployed with a driver which interfaces with a backend that perhaps
directly understands some of the GBP constructs, that system would
still need to have a core plugin configured that honors Neutron's core
resources. Hence my earlier comment that GBP extensions are
complementary to the existing core resources (in much the same way as
the existing extensions in Neutron).


OK, thanks Sumit. That clearly explains things for me.

Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 will make sure they don't violate any policy constraints
 before passing the request into the regular core/service plugins.


This is the statement that makes me trip over, and I don't understand why
GBP and Neutron Core need to be 'integrated' together as they have. Policy
decision points can be decentralized from the system under scrutiny, we
don't need to have one giant monolithic system that does everything; it's
an architectural decision that would make difficult to achieve
composability and all the other good -ilities of software systems.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 project. If someone uses the current APIs, the group policy
 plugin will make sure they don't violate any policy constraints before
 passing the request into the regular core/service plugins.


 This is the statement that makes me trip over, and I don't understand why
 GBP and Neutron Core need to be 'integrated' together as they have. Policy
 decision points can be decentralized from the system under scrutiny, we
 don't need to have one giant monolithic system that does everything; it's an
 architectural decision that would make difficult to achieve composability
 and all the other good -ilities of software systems.


Adding the GBP extension to Neutron does not change the nature of the
software architecture of Neutron making it more or less monolithic. It
fulfills a gap that is currently present in the Neutron API, namely -
to complement the current imperative abstractions with a app
-developer/deployer friendly declarative abstraction [1]. To
reiterate, it has been proposed as an “extension”, and not a
replacement of the core abstractions or the way those are consumed. If
this is understood and interpreted correctly, I doubt that there
should be reason for concern.

[1] https://review.openstack.org/#/c/89469

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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, 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 project. If someone uses the current APIs, the group
 policy plugin will make sure they don't violate any policy constraints
 before passing the request into the regular core/service plugins.


 This is the statement that makes me trip over, and I don't understand why
 GBP and Neutron Core need to be 'integrated' together as they have. Policy
 decision points can be decentralized from the system under scrutiny, we
 don't need to have one giant monolithic system that does everything; it's
 an architectural decision that would make difficult to achieve
 composability and all the other good -ilities of software systems.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 plugins and frameworks we have right now, and yes it does not make
Neutron more monolithic but certainly not less. These same very principles
have unveiled limitations we have realized need to be addressed, according
to Neutron's busy agenda. That said, if I were to be given the opportunity
to revise some architectural decisions during the new groundbreaking work
(regardless of the nature), I would.

For instance, I hate that the service plugins live in the same address
space of Neutron Server, I hate that I have one Neutron Server that does
L2, L3, IPAM, ...; we could break it down and make sure every entity can
have its own lifecycle: we can compose and integrate more easily if we did.
Isn't that what years of middleware and distributed systems taught us?

I suggested in the past that GBP would best integrate to Neutron via a
stable and RESTful interface, just like any other OpenStack project does. I
have been unable to be convinced otherwise, and I would love to be able to
change my opinion.


 It
 fulfills a gap that is currently present in the Neutron API, namely -
 to complement the current imperative abstractions with a app
 -developer/deployer friendly declarative abstraction [1]. To
 reiterate, it has been proposed as an “extension”, and not a
 replacement of the core abstractions or the way those are consumed.

If
 this is understood and interpreted correctly, I doubt that there
 should be reason for concern.


I never said that GBP did (mean to replace the core abstractions): I am
talking purely architecture and system integration. Not sure if this
statement is directed to my comment.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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,


Unfortunately they can't in this case where some policy needs to be
enforced between plugins. If we could refactor the communication between
service and core plugins to use the API as well, then we probably could
build this as a middleware.


On Fri, Aug 8, 2014 at 1: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 project. If someone uses the current APIs, the group
 policy plugin will make sure they don't violate any policy constraints
 before passing the request into the regular core/service plugins.


 This is the statement that makes me trip over, and I don't understand why
 GBP and Neutron Core need to be 'integrated' together as they have. Policy
 decision points can be decentralized from the system under scrutiny, we
 don't need to have one giant monolithic system that does everything; it's
 an architectural decision that would make difficult to achieve
 composability and all the other good -ilities of software systems.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 think that? I trip over the obstacle that prevents me from
understanding! If at all, I would blame my stupidity, not the one of the
statement :)



 Policy decision points can be decentralized from the system under
 scrutiny,

 Unfortunately they can't in this case where some policy needs to be
 enforced between plugins. If we could refactor the communication between
 service and core plugins to use the API as well, then we probably could
 build this as a middleware.


Assumed I agreed they couldn't, which I find hard to believe, instead of
going after the better approach, we stick with the less optimal one?



 On Fri, Aug 8, 2014 at 1: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 project. If someone uses the current APIs, the group
 policy plugin will make sure they don't violate any policy constraints
 before passing the request into the regular core/service plugins.


 This is the statement that makes me trip over, and I don't understand why
 GBP and Neutron Core need to be 'integrated' together as they have. Policy
 decision points can be decentralized from the system under scrutiny, we
 don't need to have one giant monolithic system that does everything; it's
 an architectural decision that would make difficult to achieve
 composability and all the other good -ilities of software systems.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 to the same principles and architectural choices made for the
 service plugins and frameworks we have right now, and yes it does not make
 Neutron more monolithic but certainly not less. These same very principles
 have unveiled limitations we have realized need to be addressed, according
 to Neutron's busy agenda. That said, if I were to be given the opportunity
 to revise some architectural decisions during the new groundbreaking work
 (regardless of the nature), I would.

 For instance, I hate that the service plugins live in the same address
 space of Neutron Server, I hate that I have one Neutron Server that does
 L2, L3, IPAM, ...; we could break it down and make sure every entity can
 have its own lifecycle: we can compose and integrate more easily if we did.
 Isn't that what years of middleware and distributed systems taught us?

 I suggested in the past that GBP would best integrate to Neutron via a
 stable and RESTful interface, just like any other OpenStack project does. I
 have been unable to be convinced otherwise, and I would love to be able to
 change my opinion.





 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

While the service plugin has scalability issues as pointed above that it
resides in neutron server, it is however stable and user configurable and a
lot of common code is executed for networking services. So while we make
the next generation services framework more distributed and scalable, it is
ok to do it under the current framework especially since it has provision
for the user to opt in when needed.




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 reusable, it's not
a prerogative of Neutron.



 While the service plugin has scalability issues as pointed above that it
 resides in neutron server, it is however stable and user configurable and a
 lot of common code is executed for networking services.


This is what static or dynamic libraries are for and reused for; I can have
a building block and reuse it many times the way I see fit keeping my
components' lifecycles separate.


 So while we make the next generation services framework more distributed
 and scalable, it is ok to do it under the current framework especially
 since it has provision for the user to opt in when needed.


A next generation services framework is not a prerequisite to integrating
two OpenStack projects via REST APIs. I don't see how we would associate
the two concepts together.






 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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
 scoping


 The framework you're referring to is common and already reusable, it's not
 a prerogative of Neutron.


Are you suggesting that Service Plugins, L3, IPAM etc become individual
endpoints, resulting in redundant authentication round-trips for each of
the components.

Wouldn't this result in degraded performance and potential consistency
issues?





 While the service plugin has scalability issues as pointed above that it
 resides in neutron server, it is however stable and user configurable and a
 lot of common code is executed for networking services.


 This is what static or dynamic libraries are for and reused for; I can
 have a building block and reuse it many times the way I see fit keeping my
 components' lifecycles separate.


 So while we make the next generation services framework more distributed
 and scalable, it is ok to do it under the current framework especially
 since it has provision for the user to opt in when needed.


 A next generation services framework is not a prerequisite to integrating
 two OpenStack projects via REST APIs. I don't see how we would associate
 the two concepts together.






 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 scoping


 The framework you're referring to is common and already reusable, it's
 not a prerogative of Neutron.


  Are you suggesting that Service Plugins, L3, IPAM etc become individual
 endpoints, resulting in redundant authentication round-trips for each of
 the components.

 Wouldn't this result in degraded performance and potential consistency
 issues?


The endpoint - in the OpenStack lingo - that exposes the API abstractions
(concepts and operations) can be, logically and physically, different from
the worker that implements these abstractions; authentication is orthogonal
to this and I am not suggesting what you mention.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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
improvement and works with ports that don't support security groups..

Neutron's current API is a logical abstraction and enforcement can be done
however one chooses to implement it. I'm really trying to understand at the
network level why GBP allows for these optimizations and performance
improvements you talked about.

You absolutely cannot enforce security groups on a firewall/router that
sits at the boundary between networks. If you try, you are lying to the
end-user because it's not enforced at the port level. The current neutron
APIs force you to decide where things like that are implemented. The higher
level abstractions give you the freedom to move the enforcement by allowing
the expression of broad connectivity requirements.

Why are you bringing up logging connections?

This was brought up as a feature proposal to FWaaS because this is a basic
firewall feature missing from OpenStack. However, this does not preclude a
FWaaS vendor from logging.

Personally, I think one could easily write up a very short document
probably less than one page with examples showing/exampling how the current
neutron API works even without a much networking background.

The difficulty of the API for establishing basic connectivity isn't really
the problem. It's when you have to compose a bunch of requirements and make
sure nothing is violating auditing and connectivity constraints that it
becomes a problem. We are arguing about the levels of abstraction. You
could also write up a short document explaining to novice programmers how
to use C to read and write database entries to an sqlite database, but that
doesn't mean it's the best level of abstraction for what the users are
trying to accomplish.

I'll let someone else explain the current GBP API because I'm not working
on that. I'm just trying to convince you of the value of declarative
network configuration.


On Thu, Aug 7, 2014 at 12:02 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 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 not sure how that's 'side stepping' any points. It removes the need for
 the user to pick between implementation details like security
 groups/FWaaS/ACLs.


 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
 improvement and works with ports that don't support security groups..

 Neutron's current API is a logical abstraction and enforcement can be done
 however one chooses to implement it. I'm really trying to understand at the
 network level why GBP allows for these optimizations and performance
 improvements you talked about.



 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts?

 It's one thing to understand the ports an application leverages and
 another to understand the differences between configuring VM firewalls,
 security groups, FWaaS, and router ACLs.


 Sure, but how does group based policy solve this. Security Groups and
 FWaaS are just different places of enforcement. Say I want different
 security enforcement on my router than on my instances. One still needs to
 know enough to tell group based policy this right?  They need to know
 enough that there are different enforcement points? How is doing this with
 Group based policy make it easier?



  I'm also curious how this GBP is really less error prone than the
 model we have today as it seems the user will basically have to tell
 neutron the same information about how he wants his networking to function.

 With GBP, the user just gives the desired end result (e.g. allow
 connectivity between endpoint groups via TCP port 22 with all connections
 logged). Without it, the user has to do the following:


 Why are you bringing up logging connections? Neutron has no concept of
 this at all today in it's code base. Is logging something related to GBP?


1. create a network/subnet for each endpoint group
2. allow all traffic on the security groups since the logging would
need to be accomplished with FWaaS
3. create an FWaaS instance
4. attach the FWaaS to both networks

 Today FWaaS api is still incomplete as there is no real point of
 enforcement 

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 switch, which doesn't violate the user's intent and buys a
 performance improvement and works with ports that don't support security
 groups..

 Neutron's current API is a logical abstraction and enforcement can be
 done however one chooses to implement it. I'm really trying to understand
 at the network level why GBP allows for these optimizations and performance
 improvements you talked about.

 You absolutely cannot enforce security groups on a firewall/router that
 sits at the boundary between networks. If you try, you are lying to the
 end-user because it's not enforced at the port level. The current neutron
 APIs force you to decide where things like that are implemented.


The current neutron API's are just logical abstractions. Where and how
things are actually enforced are 100% an implementation detail of a vendors
system.  Anyways, moving the discussion to the etherpad...



 The higher level abstractions give you the freedom to move the enforcement
 by allowing the expression of broad connectivity requirements.

Why are you bringing up logging connections?

 This was brought up as a feature proposal to FWaaS because this is a basic
 firewall feature missing from OpenStack. However, this does not preclude a
 FWaaS vendor from logging.

 Personally, I think one could easily write up a very short document
 probably less than one page with examples showing/exampling how the current
 neutron API works even without a much networking background.

 The difficulty of the API for establishing basic connectivity isn't really
 the problem. It's when you have to compose a bunch of requirements and make
 sure nothing is violating auditing and connectivity constraints that it
 becomes a problem. We are arguing about the levels of abstraction. You
 could also write up a short document explaining to novice programmers how
 to use C to read and write database entries to an sqlite database, but that
 doesn't mean it's the best level of abstraction for what the users are
 trying to accomplish.

 I'll let someone else explain the current GBP API because I'm not working
 on that. I'm just trying to convince you of the value of declarative
 network configuration.


 On Thu, Aug 7, 2014 at 12:02 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 not sure how that's 'side stepping' any points. It removes the need for
 the user to pick between implementation details like security
 groups/FWaaS/ACLs.


 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 improvement and works with ports that don't support security
 groups..

 Neutron's current API is a logical abstraction and enforcement can be
 done however one chooses to implement it. I'm really trying to understand
 at the network level why GBP allows for these optimizations and performance
 improvements you talked about.



 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts?

 It's one thing to understand the ports an application leverages and
 another to understand the differences between configuring VM firewalls,
 security groups, FWaaS, and router ACLs.


 Sure, but how does group based policy solve this. Security Groups and
 FWaaS are just different places of enforcement. Say I want different
 security enforcement on my router than on my instances. One still needs to
 know enough to tell group based policy this right?  They need to know
 enough that there are different enforcement points? How is doing this with
 Group based policy make it easier?



  I'm also curious how this GBP is really less error prone than the
 model we have today as it seems the user will basically have to tell
 neutron the same information about how he wants his networking to function.

 With GBP, the user just gives the desired end result (e.g. allow
 connectivity between endpoint groups via TCP port 22 with all connections
 logged). Without it, the user has to do the following:


 Why are you bringing up logging connections? Neutron has no concept of
 this at all today in it's code base. Is logging something related to GBP?



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:
  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 make GBP a stackforge project, that integrates with Neutron in
some
  shape or form;
 
  Another option, might be something in between, where GBP is in tree,
but
  in some sort of experimental staging area (even though I am not sure
how
  well baked this idea is).
 
  Now, as a community we all need make a decision; arguing about the fact
  that the blueprint was approved is pointless.
 I agree with you: it is possible to change your mind on a topic and
 revisit past decisions.
 In past OpenStack history we did revert merged
 commits and remove existing functionality because we felt it wasn't that
 much of a great idea after all. Here we are talking about making the
 right decision *before* the final merging and shipping into a release,
 which is kind of an improvement. The spec system was supposed to help
 limit such cases, but it's not bullet-proof.

 In the end, if there is no consensus on that question within the Neutron
 project (and I hear both sides have good arguments), our governance
 gives the elected Neutron PTL the power to make the final call. If the
 disagreement is between projects (like if Nova disagreed with the
 Neutron decision), then the issue could be escalated to the TC.


It is good to know that the OpenStack governance provides a way to resolve
these issues but I really hope that we can reach a consensus.

Best,

Mohammad



 Regards,

 --
 Thierry Carrez (ttx)

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-07 Thread Subrahmanyam Ongole
I am one of the developers on the project, so I have a strong preference
for option (1).

I think a 3rd option is also possible, which offers a scale down version of
GBP APIs. Contracts could be added in kilo. Provide EndPoints,
EndPointGroups, Rules and Policies. This is the simpler approach suggested
in GBP document, where you have a policy with a single rule (classifier 
action) applied between 2 EPGs. This approach minimizes complexity and
therefore saves precious reviewer's time. This requires some code reorg,
which may not be preferable to other developers on the project.

Alternatively, contracts could be added as optional vendor extensions in
Juno.



On Wed, Aug 6, 2014 at 8:50 PM, Alan Kavanagh alan.kavan...@ericsson.com
wrote:

 +1
 I believe Pedro has a very valid point here, and that is the the
 community to approve the spec and that decision should be respected. It
 makes sense to again clearly denote the process and governance and have
 this noted on the thread Stefano started earlier today.

 /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 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 drivers that spoke proprietary device APIs.
 
  If this is the end-goal, it should be stated more clearly, IMO.

 I believe that people should be considered innocent until proven
 otherwise. Is there a reason to believe there is some hidden reason behind
 this proposal ? It seems to me that this is uncalled for.

 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 was their intent. As far as i know
 most plugins talk to a proprietary API.

 I happen to disagree technically with a couple of choices made by this
 proposal; but the blueprint was approved. Which means that i lost the
 argument, or didn't raise it on time, or didn't argue convincingly...
 regardless of the reason, the time to argue about the goal has passed. The
 decision of the community was to approve the spec and that decision should
 be respected.

   Pedro.
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

Thanks
OSM
(Subrahmanyam Ongole)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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
 revision (e.g. naming?);
 - We make GBP a stackforge project, that integrates with Neutron in some
 shape or form;
 
 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).
 
 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless.

I agree with you: it is possible to change your mind on a topic and
revisit past decisions. In past OpenStack history we did revert merged
commits and remove existing functionality because we felt it wasn't that
much of a great idea after all. Here we are talking about making the
right decision *before* the final merging and shipping into a release,
which is kind of an improvement. The spec system was supposed to help
limit such cases, but it's not bullet-proof.

In the end, if there is no consensus on that question within the Neutron
project (and I hear both sides have good arguments), our governance
gives the elected Neutron PTL the power to make the final call. If the
disagreement is between projects (like if Nova disagreed with the
Neutron decision), then the issue could be escalated to the TC.

Regards,

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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.


Because most skilled developers such as  Mark, Oleg and Carl are
working hard for this making happen.
I'm also trying to POC non-DVR approach such as
migrating nova-network directly to the neutron. (Sorry, this is off
topic, but if you are interested in this,
https://docs.google.com/presentation/d/12w28HhNpLltSpA6pJvKWBiqeEusaI-NM-OZo8HNyH2w/edit#slide=id.p
is my thought )

Even if codes for GBP and Nova parity is really independent, so it
won't conflict.
Note that if you have any task item related with nova parity work, plz ping me.

[Topic2] Neutron community decision making process

I'm super lazy guy, so I'll be very disappointed the code i write rejected..
( http://openstackreactions.enovance.com/2013/09/when-my-patch-get-2/ )

We are discussing this spec for couple of releases…
IMO, we should have voting process such as IETF or let PTL make final
decision like TTX saying.

[Topic3] Group based policy specs

I'm not jumped in this one. I have already shared my thought on this.
This is still extension proposal. so we should let user choose use
this or not.
If it is proven for wide use, then we can discuss making it for core API.

I'm also working on another extension spec. It is deferred for next
release, 
(http://openstackreactions.enovance.com/2014/04/getting-told-that-this-feature-will-not-be-accepted-before-next-release/
)

but if you have any interest on this plz ping me

http://docs-draft.openstack.org/12/93112/16/check/gate-neutron-specs-docs/afb346d/doc/build/html/specs/juno/security_group_action.html
http://docs-draft.openstack.org/12/93112/16/check/gate-neutron-specs-docs/afb346d/doc/build/html/specs/juno/security_group_for_network.html

[Topic4] Where we develop group based policy stuffs. And generally,
service related stuffs.

I do remember the LBaaS new project meeting at the Summit. I remember
someone says I don't trust neutron makes this feature make it working
in Juno timeframe..  I guess he was right..

We should have a new project for service related stuffs.
( 
http://openstackreactions.enovance.com/2013/11/when-a-new-openstack-project-announce-itself/
)


Best
Nachi

2014-08-07 19:23 GMT+09:00 Thierry Carrez thie...@openstack.org:
 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
 revision (e.g. naming?);
 - We make GBP a stackforge project, that integrates with Neutron in some
 shape or form;

 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).

 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless.

 I agree with you: it is possible to change your mind on a topic and
 revisit past decisions. In past OpenStack history we did revert merged
 commits and remove existing functionality because we felt it wasn't that
 much of a great idea after all. Here we are talking about making the
 right decision *before* the final merging and shipping into a release,
 which is kind of an improvement. The spec system was supposed to help
 limit such cases, but it's not bullet-proof.

 In the end, if there is no consensus on that question within the Neutron
 project (and I hear both sides have good arguments), our governance
 gives the elected Neutron PTL the power to make the final call. If the
 disagreement is between projects (like if Nova disagreed with the
 Neutron decision), then the issue could be escalated to the TC.

 Regards,

 --
 Thierry Carrez (ttx)

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 networking
level to actually figure out why optimizations such as this one are enabled
via GBP and not the model we have:

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
improvement and works with ports that don't support security groups.



On Wed, Aug 6, 2014 at 7:48 PM, Kevin Benton blak...@gmail.com wrote:

 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 strong networking background, and the latter is basically just
 stating the requirements and letting Neutron figure out how to implement
 it.

 So are you saying that GBP allows someone to be able to configure an
application that at the end of the day is equivalent  to
networks/router/FWaaS rules without understanding networking concepts? I'm
also curious how this GBP is really less error prone than the model we have
today as it seems the user will basically have to tell neutron the same
information about how he wants his networking to function.



 Just stating requirements becomes even more important when something like
 the logging requirement comes from someone other than the app deployer
 (e.g. a security team). In the above example, someone could set everything
 up using security groups; however, when the logging requirement came in
 from the security team, they would have to undo all of that work and
 replace it with something like FWaaS that can centrally log all of the
 connections.

 It's the difference between using puppet and bash scripts. Sure you can
 write a script that uses awk/sed to ensure that an ini file has a
 particular setting and then restart a service if the setting is changed,
 but it's much easier and less error prone to just write a puppet manifest
 that uses the INI module with a pointer to the file, the section name, the
 key, and the value with a notification to restart the service.



 On Wed, Aug 6, 2014 at 7: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 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 security groups API, you are forcing it to be
 implemented there.


 I still have no idea what group based policy is buying us then. It seems
 to me that the key point we've identified going backing and forth here is
 the difference between the current model and the GBP model is that GBP
 constricts topology which allows us to write these types of enforcement
 rules. The reason we want this is because it yields performance
 optimizations (for some reason, which I don't think we've gotten into).
 Would you agree this is accurate?

 Honestly, I know a lot of work has been put into this. I haven't said I'm
 for or against it either. I'm really just trying to understand what is the
 motivation for this and why does it make neutron better.

 Best,

 Aaron




 On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



  On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 contact
 these devices on those ports unless they come from the allowed IP
 addresses. If you tried to enforce this at the router you would be
 violating that specification because devices in 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 user to pick between implementation details like security
groups/FWaaS/ACLs.

So are you saying that GBP allows someone to be able to configure an
application that at the end of the day is equivalent  to
networks/router/FWaaS rules without understanding networking concepts?

It's one thing to understand the ports an application leverages and another
to understand the differences between configuring VM firewalls, security
groups, FWaaS, and router ACLs.

 I'm also curious how this GBP is really less error prone than the model
we have today as it seems the user will basically have to tell neutron the
same information about how he wants his networking to function.

With GBP, the user just gives the desired end result (e.g. allow
connectivity between endpoint groups via TCP port 22 with all connections
logged). Without it, the user has to do the following:

   1. create a network/subnet for each endpoint group
   2. allow all traffic on the security groups since the logging would need
   to be accomplished with FWaaS
   3. create an FWaaS instance
   4. attach the FWaaS to both networks
   5. add an FWaaS policy and the FWaaS rules to allow the correct traffic

The declarative approach is less error prone because the user can give
neutron the desired state of connectivity rather than a mentally compiled
set of instructions describing how to configure a bunch of individual
network components. How well do you think someone will handle the latter
approach that got all of their networking knowledge from one college course
5 years ago?

IIRC one of the early nova parity requests was an API to automagically
setup a neutron network and router so no extra work would be required to
get instances connected to the Internet. That wasn't requested because
people thought neutron networks were too easy to setup already. :-)


On Thu, Aug 7, 2014 at 9:10 AM, Aaron Rosen aaronoro...@gmail.com wrote:

 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 networking
 level to actually figure out why optimizations such as this one are enabled
 via GBP and not the model we have:


 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
 improvement and works with ports that don't support security groups.



 On Wed, Aug 6, 2014 at 7:48 PM, Kevin Benton blak...@gmail.com wrote:

 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 strong networking background, and the latter is basically just
 stating the requirements and letting Neutron figure out how to implement
 it.

 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts? I'm
 also curious how this GBP is really less error prone than the model we have
 today as it seems the user will basically have to tell neutron the same
 information about how he wants his networking to function.



 Just stating requirements becomes even more important when something like
 the logging requirement comes from someone other than the app deployer
 (e.g. a security team). In the above example, someone could set everything
 up using security groups; however, when the logging requirement came in
 from the security team, they would have to undo all of that work and
 replace it with something like FWaaS that can centrally log all of the
 connections.

 It's the difference between using puppet and bash scripts. Sure you can
 write a script that uses awk/sed to ensure that an ini file has a
 particular setting and then restart a service if the setting is changed,
 but it's much easier and less error prone to just write a puppet manifest
 that uses the INI module with a pointer to the file, the section name, the
 key, and the value with a notification to restart the service.



 On Wed, Aug 6, 2014 at 7: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 

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 not sure how that's 'side stepping' any points. It removes the need for
 the user to pick between implementation details like security
 groups/FWaaS/ACLs.


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
improvement and works with ports that don't support security groups..

Neutron's current API is a logical abstraction and enforcement can be done
however one chooses to implement it. I'm really trying to understand at the
network level why GBP allows for these optimizations and performance
improvements you talked about.



 So are you saying that GBP allows someone to be able to configure an
 application that at the end of the day is equivalent  to
 networks/router/FWaaS rules without understanding networking concepts?

 It's one thing to understand the ports an application leverages and
 another to understand the differences between configuring VM firewalls,
 security groups, FWaaS, and router ACLs.


Sure, but how does group based policy solve this. Security Groups and FWaaS
are just different places of enforcement. Say I want different security
enforcement on my router than on my instances. One still needs to know
enough to tell group based policy this right?  They need to know enough
that there are different enforcement points? How is doing this with Group
based policy make it easier?



  I'm also curious how this GBP is really less error prone than the model
 we have today as it seems the user will basically have to tell neutron the
 same information about how he wants his networking to function.

 With GBP, the user just gives the desired end result (e.g. allow
 connectivity between endpoint groups via TCP port 22 with all connections
 logged). Without it, the user has to do the following:


Why are you bringing up logging connections? Neutron has no concept of this
at all today in it's code base. Is logging something related to GBP?


1. create a network/subnet for each endpoint group
2. allow all traffic on the security groups since the logging would
need to be accomplished with FWaaS
3. create an FWaaS instance
4. attach the FWaaS to both networks

 Today FWaaS api is still incomplete as there is no real point of
enforcement in it's api (though it really seems that it should just be
router ports) it's just global on the router right  now.



1. add an FWaaS policy and the FWaaS rules to allow the correct traffic

 I'd more or less agree with these steps. Would you mind also giving the
steps involved in group based policy so we can compare?



 The declarative approach is less error prone because the user can give
 neutron the desired state of connectivity rather than a mentally compiled
 set of instructions describing how to configure a bunch of individual
 network components. How well do you think someone will handle the latter
 approach that got all of their networking knowledge from one college course
 5 years ago?


Personally, I think one could easily write up a very short document
probably less than one page with examples showing/exampling how the current
neutron API works even without a much networking background.  The funny
thing is I've been trying to completely understand the proposed group
policy api for a little while now and I'm still having trouble. Seems like
we're taking abstractions that are quite well known/understood and changing
them to a different model that requires one to know about this new
terminology:


Endpoint (EP): An L2/L3 addressable entity.
Endpoint Group (EPG): A collection of endpoints.
Contract: It defines how the application services provided by an EPG can be
accessed. In effect it specifies how an EPG communicates with other EPGs. A
Contract consists of Policy Rules.
Policy Rule: These are individual rules used to define the communication
criteria between EPGs. Each rule contains a Filter, Classifier, and Action.
Classifier: Characterizes the traffic that a particular Policy Rule acts
on. Corresponding action is taken on traffic that satisfies this
classification criteria.
Action: The action that is taken for a matching Policy Rule defined in a
Contract.
Filter: Provides a way to tag a Policy Rule with Capability and Role labels.
Capability: It is a Policy Label that defines what part of a Contract a
particular EPG provides.
Role: It is a Policy Label that defines what part of a Contract an EPG
wants to consume.
Contract Scope: An EPG conveys its intent to provide or consume a Contract
(or its part) by 

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 a new production project for an internal private cloud
deployment targeting Juno release where we plan to introduce the
capabilities based on using Group Policy and we don't want to see it
delayed.
We strongly request/vote to see this complete as proposed without such
changes to allow to move forward with the evolution of the network
capabilities


Hi Stefano,

AFAICT, there is nothing that can be done with the GBP API that cannot 
be done with the low-level regular Neutron API.


Further, if the Nova integration of the GBP API does not occur in the 
Juno timeframe, what benefit will GBP in Neutron give you? Specifics on 
the individual API calls that you would change would be most appreciated.


Thanks in advance for your input!
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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
 critical need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely with all
 existing core plugins. Additionally, we believe that this declarative
 approach is what is needed to properly integrate advanced services into
 Neutron, and will go a long way towards resolving the difficulties so far
 trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
 model.

My problem with the current blueprint and that comment above is it does not
provide any evidence or data of where the current neutron abstractions
(ports/networks/subnets/routers) provide difficulties and what benefit this
new model will provide.

In the current proposed implementation of group policy, it's implementation
maps onto the existing neutron primitives and the neutron back end(s)
remains unchanged. Because of this one can map the new abstractions onto
the previous ones so I'm curious why we want to move this complexity into
neutron and not have it done externally similarly to how heat works or a
client that abstracts this complexity on it's own end.

From the group-based policy blueprint that was submitted [1]:


The current Neutron model of networks, ports, subnets, routers, and security
 groups provides the necessary building blocks to build a logical network
 topology for connectivity. However, it does not provide the right level
 of abstraction for an application administrator who understands the
 application's details (like application port numbers), but not the
 infrastructure details likes networks and routes.

It looks to me that application administrators still need to understand
network primitives as the concept of networks/ports/routers are still
present though just carrying a different name. For example, in
ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
that you use to describe a l2_network and contains an attribute
l3_policy_id which is used to describe an L3 network. This looks similar to
the abstraction we have today where a l2_policy (network) then can have
multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
how the GBP abstraction really provides a different level of abstraction
for application administrators.


 Not only that, the current
 abstraction puts the burden of maintaining the consistency of the network
 topology on the user. The lack of application developer/administrator
 focussed
 abstractions supported by a declarative model make it hard for those users
 to consume Neutron as a connectivity layer.

What is the problem in the current abstraction that puts a burden of
maintaining the consistency of networking topology on users? It seems to me
that the complexity of having to know about topology should be abstracted
at the client layer if desired (and neutron should expose the basic
building blocks for networking). For example, Horizon/Heat or the CLI could
hide the requirement of topology by automatically creating a GROUP  (which
is a network+subnet on a router uplinked to an external network)
simplifying this need for the tenant to understand topology. In addition,
topology still seems to be present in the group policy model proposed just
in a different way as I see it.

From the proposed change section the following is stated:


This proposal suggests a model that allows application administrators to
 express their networking requirements using group and policy abstractions,
 with
 the specifics of policy enforcement and implementation left to the
 underlying
 policy driver. The main advantage of the extensions described in this
 blueprint
 is that they allow for an application-centric interface to Neutron that
 complements the existing network-centric interface.


How is the Application-centric interface complementary to the
network-centric interface?  Is the intention that one would use both
interfaces at one once?

More specifically the new abstractions will achieve the following:
 * Show clear separation of concerns between application and infrastructure
 administrator.


I'm not quite sure I understand this point, how is this different than what
we have today?


 - The application administrator can then deal with a higher level
 abstraction
 that does not concern itself with networking specifics like
 networks/routers/etc.


It seems like the proposed abstraction still requires one to concern
themselves with networking specifics (l2_policies, l3_policies).  I'd
really like to see more evidence backing this. Now they have to deal with
specifies like: Endpoint, Endpoint Group, Contract, Policy Rule,

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 residing
in the same IP subnet (an example of this is a bump-in-the-wire network
appliance).

I've looked around regular Neutron and all I've come up with so far is:
(1) use security groups on the ports
(2) set allow_overlapping_ips to true, set up two networks with
identical CIDR block subnets and disjoint allocation pools and put a
vRouter between them.

Now #1 only works for basic allow/deny access and adds the complexity of
needing to specify per-IP address security rules, which means you need the
ports to have IP addresses already and then manually add them into the
security groups, which doesn't seem particularly very orchestration
friendly.

Now #2 handles both allow/deny access as well as provides a potential
attachment point for other behaviors, *but* you have to know to set up the
disjoint allocation pools, and your depending on your drivers to handle the
case of a router that isn't really a router (i.e. it's got two interfaces
in the same subnet, possibly with the same address (unless you thought of
that when you set things up)).

You can say that both of these are *possible*, but they both look more
complex to me than just having two groups of ports and specifying a policy
between them.

Ryan Moats___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 aaronoro...@gmail.com wrote:

 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
 critical need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely with all
 existing core plugins. Additionally, we believe that this declarative
 approach is what is needed to properly integrate advanced services into
 Neutron, and will go a long way towards resolving the difficulties so far
 trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
 model.

 My problem with the current blueprint and that comment above is it does
 not provide any evidence or data of where the current neutron abstractions
 (ports/networks/subnets/routers) provide difficulties and what benefit this
 new model will provide.

 In the current proposed implementation of group policy, it's
 implementation maps onto the existing neutron primitives and the neutron
 back end(s) remains unchanged. Because of this one can map the new
 abstractions onto the previous ones so I'm curious why we want to move this
 complexity into neutron and not have it done externally similarly to how
 heat works or a client that abstracts this complexity on it's own end.

 From the group-based policy blueprint that was submitted [1]:


 The current Neutron model of networks, ports, subnets, routers, and
 security
 groups provides the necessary building blocks to build a logical network
 topology for connectivity. However, it does not provide the right level
 of abstraction for an application administrator who understands the
 application's details (like application port numbers), but not the
 infrastructure details likes networks and routes.

 It looks to me that application administrators still need to understand
 network primitives as the concept of networks/ports/routers are still
 present though just carrying a different name. For example, in
 ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
 that you use to describe a l2_network and contains an attribute
 l3_policy_id which is used to describe an L3 network. This looks similar to
 the abstraction we have today where a l2_policy (network) then can have
 multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
 how the GBP abstraction really provides a different level of abstraction
 for application administrators.


  Not only that, the current
 abstraction puts the burden of maintaining the consistency of the network
 topology on the user. The lack of application developer/administrator
 focussed
 abstractions supported by a declarative model make it hard for those users
 to consume Neutron as a connectivity layer.

 What is the problem in the current abstraction that puts a burden of
 maintaining the consistency of networking topology on users? It seems to me
 that the complexity of having to know about topology should be abstracted
 at the client layer if desired (and neutron should expose the basic
 building blocks for networking). For example, Horizon/Heat or the CLI could
 hide the requirement of topology by automatically creating a GROUP  (which
 is a network+subnet on a router uplinked to an external network)
 simplifying this need for the tenant to understand topology. In addition,
 topology still seems to be present in the group policy model proposed just
 in a different way as I see it.

 From the proposed change section the following is stated:


 This proposal suggests a model that allows application administrators to
 express their networking requirements using group and policy
 abstractions, with
 the specifics of policy enforcement and implementation left to the
 underlying
 policy driver. The main advantage of the extensions described in this
 blueprint
 is that they allow for an application-centric interface to Neutron that
 complements the existing network-centric interface.


 How is the Application-centric interface complementary to the
 network-centric interface?  Is the intention that one would use both
 interfaces at one once?

  More specifically the new abstractions will achieve the following:
 * Show clear separation of concerns between application and infrastructure
 administrator.


 I'm not quite sure I understand this point, how is this different than
 what we have today?


 - The application administrator can then deal with a higher level
 

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 on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-wire
 network appliance).

 Would you mind explaining what behavior you want between the two
collection of ports?


 I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with identical
 CIDR block subnets and disjoint allocation pools and put a vRouter between
 them.

 Now #1 only works for basic allow/deny access and adds the complexity of
 needing to specify per-IP address security rules, which means you need the
 ports to have IP addresses already and then manually add them into the
 security groups, which doesn't seem particularly very orchestration
 friendly.


I believe the referential security group rules solve this problem (unless
I'm not understanding):

neutron security-group-create group1
neutron security-group-create group2

# allow members of group1 to ssh into group2 (but not the other way around):
neutron security-group-rule-create --direction ingress --port-range-min 22
--port-range-max 22 --protocol TCP --remote-group-id group1 group2

# allow members of group2 to be able to access TCP 80 from members of
group1 (but not the other way around):
neutron security-group-rule-create --direction ingress --port-range-min 80
--port-range-max 80 --protocol TCP --remote-group-id group2 group1

# Now when you create ports just place these in the desired security groups
and neutron will automatically handle this orchestration for you (and you
don't have to deal with ip_addresses and updates).

neutron port-create --security-groups group1 network1
neutron port-create --security-groups group2 network1



 Now #2 handles both allow/deny access as well as provides a potential
 attachment point for other behaviors, *but* you have to know to set up the
 disjoint allocation pools, and your depending on your drivers to handle the
 case of a router that isn't really a router (i.e. it's got two interfaces
 in the same subnet, possibly with the same address (unless you thought of
 that when you set things up)).


Are you talking about the firewall as a service stuff here?


 You can say that both of these are *possible*, but they both look more
 complex to me than just having two groups of ports and specifying a policy
 between them.


Would you mind proposing how this is done in the Group policy api? From
what I can tell in the new proposed api you'd need to map both of these
groups to different endpoints i.e networks.



 Ryan Moats


 Best,

Aaron

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 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 aaronoro...@gmail.com wrote:

 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
 critical need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely with all
 existing core plugins. Additionally, we believe that this declarative
 approach is what is needed to properly integrate advanced services into
 Neutron, and will go a long way towards resolving the difficulties so far
 trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
 model.

 My problem with the current blueprint and that comment above is it does
 not provide any evidence or data of where the current neutron abstractions
 (ports/networks/subnets/routers) provide difficulties and what benefit this
 new model will provide.

 In the current proposed implementation of group policy, it's
 implementation maps onto the existing neutron primitives and the neutron
 back end(s) remains unchanged. Because of this one can map the new
 abstractions onto the previous ones so I'm curious why we want to move this
 complexity into neutron and not have it done externally similarly to how
 heat works or a client that abstracts this complexity on it's own end.

 From the group-based policy blueprint that was submitted [1]:


 The current Neutron model of networks, ports, subnets, routers, and
 security
 groups provides the necessary building blocks to build a logical network
 topology for connectivity. However, it does not provide the right level
 of abstraction for an application administrator who understands the
 application's details (like application port numbers), but not the
 infrastructure details likes networks and routes.

 It looks to me that application administrators still need to understand
 network primitives as the concept of networks/ports/routers are still
 present though just carrying a different name. For example, in
 ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
 that you use to describe a l2_network and contains an attribute
 l3_policy_id which is used to describe an L3 network. This looks similar to
 the abstraction we have today where a l2_policy (network) then can have
 multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
 how the GBP abstraction really provides a different level of abstraction
 for application administrators.


  Not only that, the current
 abstraction puts the burden of maintaining the consistency of the network
 topology on the user. The lack of application developer/administrator
 focussed
 abstractions supported by a declarative model make it hard for those
 users
 to consume Neutron as a connectivity layer.

 What is the problem in the current abstraction that puts a burden of
 maintaining the consistency of networking topology on users? It seems to me
 that the complexity of having to know about topology should be abstracted
 at the client layer if desired (and neutron should expose the basic
 building blocks for networking). For example, Horizon/Heat or the CLI could
 hide the requirement of topology by automatically creating a GROUP  (which
 is a network+subnet on a router uplinked to an external network)
 simplifying this need for the tenant to understand topology. In addition,
 topology still seems to be present in the group policy model proposed just
 in a different way as I see it.

 From the proposed change section the following is stated:


 This proposal suggests a model that allows application administrators to
 express their networking requirements using group and policy
 abstractions, with
 the specifics of policy enforcement and implementation left to the
 underlying
 policy driver. The main advantage of the extensions described in this
 blueprint
 is that they allow for an application-centric interface to Neutron that
 complements the existing network-centric interface.


 How is the Application-centric interface complementary to the
 network-centric interface?  Is the intention that one would use both
 interfaces at one once?

  More specifically the new abstractions will achieve the following:
 * Show clear separation of 

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:

 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 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 aaronoro...@gmail.com wrote:

 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
 critical need for a more usable, declarative, intent-based interface for
 cloud application developers and deployers, that can co-exist with
 Neutron's current networking-hardware-oriented API and work nicely with all
 existing core plugins. Additionally, we believe that this declarative
 approach is what is needed to properly integrate advanced services into
 Neutron, and will go a long way towards resolving the difficulties so far
 trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current Neutron
 model.

 My problem with the current blueprint and that comment above is it does
 not provide any evidence or data of where the current neutron abstractions
 (ports/networks/subnets/routers) provide difficulties and what benefit this
 new model will provide.

 In the current proposed implementation of group policy, it's
 implementation maps onto the existing neutron primitives and the neutron
 back end(s) remains unchanged. Because of this one can map the new
 abstractions onto the previous ones so I'm curious why we want to move this
 complexity into neutron and not have it done externally similarly to how
 heat works or a client that abstracts this complexity on it's own end.

 From the group-based policy blueprint that was submitted [1]:


 The current Neutron model of networks, ports, subnets, routers, and
 security
 groups provides the necessary building blocks to build a logical network
 topology for connectivity. However, it does not provide the right level
 of abstraction for an application administrator who understands the
 application's details (like application port numbers), but not the
 infrastructure details likes networks and routes.

 It looks to me that application administrators still need to understand
 network primitives as the concept of networks/ports/routers are still
 present though just carrying a different name. For example, in
 ENDPOINT_GROUPS there is an attribute l2_policy_id which maps to something
 that you use to describe a l2_network and contains an attribute
 l3_policy_id which is used to describe an L3 network. This looks similar to
 the abstraction we have today where a l2_policy (network) then can have
 multiple l3_policies (subnets) mapping to it.  Because of this I'm curious
 how the GBP abstraction really provides a different level of abstraction
 for application administrators.


  Not only that, the current
 abstraction puts the burden of maintaining the consistency of the
 network
 topology on the user. The lack of application developer/administrator
 focussed
 abstractions supported by a declarative model make it hard for those
 users
 to consume Neutron as a connectivity layer.

 What is the problem in the current abstraction that puts a burden of
 maintaining the consistency of networking topology on users? It seems to me
 that the complexity of having to know about topology should be abstracted
 at the client layer if desired (and neutron should expose the basic
 building blocks for networking). For example, Horizon/Heat or the CLI could
 hide the requirement of topology by automatically creating a GROUP  (which
 is a network+subnet on a router uplinked to an external network)
 simplifying this need for the tenant to understand topology. In addition,
 topology still seems to be present in the group policy model proposed just
 in a different way as I see it.

 From the proposed change section the following is stated:


 This proposal suggests a model that allows application administrators to
 express their networking requirements using group and policy
 abstractions, with
 the specifics of policy enforcement and implementation left to the
 underlying
 policy driver. The main advantage of the extensions described in this
 blueprint
 is that they allow for an application-centric interface to Neutron that
 

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, Aug 6, 2014 at 9:12 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 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 on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-wire
 network appliance).

 Would you mind explaining what behavior you want between the two
 collection of ports?


  I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with
 identical CIDR block subnets and disjoint allocation pools and put a
 vRouter between them.

 Now #1 only works for basic allow/deny access and adds the complexity of
 needing to specify per-IP address security rules, which means you need the
 ports to have IP addresses already and then manually add them into the
 security groups, which doesn't seem particularly very orchestration
 friendly.


 I believe the referential security group rules solve this problem (unless
 I'm not understanding):

 neutron security-group-create group1
 neutron security-group-create group2

 # allow members of group1 to ssh into group2 (but not the other way
 around):
 neutron security-group-rule-create --direction ingress --port-range-min 22
 --port-range-max 22 --protocol TCP --remote-group-id group1 group2

 # allow members of group2 to be able to access TCP 80 from members of
 group1 (but not the other way around):
 neutron security-group-rule-create --direction ingress --port-range-min 80
 --port-range-max 80 --protocol TCP --remote-group-id group2 group1

 # Now when you create ports just place these in the desired security
 groups and neutron will automatically handle this orchestration for you
 (and you don't have to deal with ip_addresses and updates).

 neutron port-create --security-groups group1 network1
 neutron port-create --security-groups group2 network1



 Now #2 handles both allow/deny access as well as provides a potential
 attachment point for other behaviors, *but* you have to know to set up the
 disjoint allocation pools, and your depending on your drivers to handle the
 case of a router that isn't really a router (i.e. it's got two interfaces
 in the same subnet, possibly with the same address (unless you thought of
 that when you set things up)).


 Are you talking about the firewall as a service stuff here?


  You can say that both of these are *possible*, but they both look more
 complex to me than just having two groups of ports and specifying a policy
 between them.


 Would you mind proposing how this is done in the Group policy api? From
 what I can tell in the new proposed api you'd need to map both of these
 groups to different endpoints i.e networks.



 Ryan Moats


 Best,

 Aaron

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 create an endpointgroup. What is being done
implicitly here? I fail to see the difference.



 Also, I agree with Kevin when he says that this is a whole different
 discussion.

 Thanks,
 Ivar.


 On Wed, Aug 6, 2014 at 9:12 PM, Aaron Rosen aaronoro...@gmail.com wrote:

 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 on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-wire
 network appliance).

 Would you mind explaining what behavior you want between the two
 collection of ports?


  I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with
 identical CIDR block subnets and disjoint allocation pools and put a
 vRouter between them.

 Now #1 only works for basic allow/deny access and adds the complexity of
 needing to specify per-IP address security rules, which means you need the
 ports to have IP addresses already and then manually add them into the
 security groups, which doesn't seem particularly very orchestration
 friendly.


 I believe the referential security group rules solve this problem (unless
 I'm not understanding):

 neutron security-group-create group1
 neutron security-group-create group2

 # allow members of group1 to ssh into group2 (but not the other way
 around):
 neutron security-group-rule-create --direction ingress --port-range-min
 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2

 # allow members of group2 to be able to access TCP 80 from members of
 group1 (but not the other way around):
 neutron security-group-rule-create --direction ingress --port-range-min
 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1

 # Now when you create ports just place these in the desired security
 groups and neutron will automatically handle this orchestration for you
 (and you don't have to deal with ip_addresses and updates).

 neutron port-create --security-groups group1 network1
 neutron port-create --security-groups group2 network1



 Now #2 handles both allow/deny access as well as provides a potential
 attachment point for other behaviors, *but* you have to know to set up the
 disjoint allocation pools, and your depending on your drivers to handle the
 case of a router that isn't really a router (i.e. it's got two interfaces
 in the same subnet, possibly with the same address (unless you thought of
 that when you set things up)).


 Are you talking about the firewall as a service stuff here?


  You can say that both of these are *possible*, but they both look more
 complex to me than just having two groups of ports and specifying a policy
 between them.


  Would you mind proposing how this is done in the Group policy api? From
 what I can tell in the new proposed api you'd need to map both of these
 groups to different endpoints i.e networks.



 Ryan Moats


 Best,

 Aaron

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 like there is a point to
this code being in Neutron since, as you said, the abstraction could happen
at a client. However, this changes once new mapping drivers can be added
that implement things differently.

Let's take the security groups example. Using the security groups API
directly is imperative (put a firewall rule on this port that blocks this
IP) compared to a higher level declarative abstraction (make sure these
two endpoints cannot communicate). With the former, the ports must support
security groups and there is nowhere except for the firewall rules on that
port to implement it without violating the user's expectation. 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 improvement and
works with ports that don't support security groups.

Group based policy is trying to move the requests into the declarative
abstraction so optimizations like the one above can be made.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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 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 same IP subnet (an example of this is a bump-in-the-
 wire network appliance).

 Would you mind explaining what behavior you want between the two
 collection of ports?

That's the point - I want a framework that will work regardless of the
specifics of the behavior later on.

 I've looked around regular Neutron and all I've come up with so far is:
 (1) use security groups on the ports
 (2) set allow_overlapping_ips to true, set up two networks with
 identical CIDR block subnets and disjoint allocation pools and put a
 vRouter between them.

 Now #1 only works for basic allow/deny access and adds the
 complexity of needing to specify per-IP address security rules,
 which means you need the ports to have IP addresses already and then
 manually add them into the security groups, which doesn't seem
 particularly very orchestration friendly.

 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 neutron security-group-create group1
 neutron security-group-create group2

 # allow members of group1 to ssh into group2 (but not the other way
around):
 neutron security-group-rule-create --direction ingress --port-range-
 min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2

 # allow members of group2 to be able to access TCP 80 from members
 of group1 (but not the other way around):
 neutron security-group-rule-create --direction ingress --port-range-
 min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1

 # Now when you create ports just place these in the desired security
 groups and neutron will automatically handle this orchestration for
 you (and you don't have to deal with ip_addresses and updates).

 neutron port-create --security-groups group1 network1
 neutron port-create --security-groups group2 network1

While those rule instances aren't particularly interesting, I concede that
security groups can handle allow/deny. However, allow/deny is the least
interesting part of the problem :)

 Now #2 handles both allow/deny access as well as provides a
 potential attachment point for other behaviors, *but* you have to
 know to set up the disjoint allocation pools, and your depending on
 your drivers to handle the case of a router that isn't really a
 router (i.e. it's got two interfaces in the same subnet, possibly
 with the same address (unless you thought of that when you set things
up)).

 Are you talking about the firewall as a service stuff here?

No, I'm being more general than any of the curret *aaS items, I'm thinking
of the general service insertion case.

 You can say that both of these are *possible*, but they both look
 more complex to me than just having two groups of ports and
 specifying a policy between them.

 Would you mind proposing how this is done in the Group policy api?
 From what I can tell in the new proposed api you'd need to map both
 of these groups to different endpoints i.e networks.

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 can specify
endpoint-group on port create

neutron grouppolicy-endpoint-group-create group1
neutron grouppolicy-endpoint-group-create group2
neutron port-create --endpoint-group group1 network1
neutron port-create --endpoint-group group2 network1
neutron grouppolicy-policy-action-create action
neutron grouppolicy-policy-classifier-create classifier
neutron grouppolicy-policy-rule-create --action action --classifier
classifer rule
neutron policy-apply rule group1 group2

One major difference between GP and current neutron (other than security
groups) is in your last statement about tying things to networks.  Like
security groups, groups in GP can have ports that span networks.  Unlike
security groups, GP allows more rich policy than just allow.

That of course begs the question of extending security groups (think this
blueprint https://review.openstack.org/#/c/93112/ ) but that approach may
have its own issues.

Ryan



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

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 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 create an endpointgroup. What is being done
 implicitly here? I fail to see the difference.



 Also, I agree with Kevin when he says that this is a whole different
 discussion.

 Thanks,
 Ivar.


 On Wed, Aug 6, 2014 at 9:12 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:

 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 on that, Jay :)

 How exactly do I specify behavior between two collections of ports
 residing in the same IP subnet (an example of this is a bump-in-the-wire
 network appliance).

 Would you mind explaining what behavior you want between the two
 collection of ports?


  I've looked around regular Neutron and all I've come up with so far
 is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with
 identical CIDR block subnets and disjoint allocation pools and put a
 vRouter between them.

 Now #1 only works for basic allow/deny access and adds the complexity
 of needing to specify per-IP address security rules, which means you need
 the ports to have IP addresses already and then manually add them into the
 security groups, which doesn't seem particularly very orchestration
 friendly.


 I believe the referential security group rules solve this problem
 (unless I'm not understanding):

 neutron security-group-create group1
 neutron security-group-create group2

 # allow members of group1 to ssh into group2 (but not the other way
 around):
 neutron security-group-rule-create --direction ingress --port-range-min
 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2

 # allow members of group2 to be able to access TCP 80 from members of
 group1 (but not the other way around):
 neutron security-group-rule-create --direction ingress --port-range-min
 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1

 # Now when you create ports just place these in the desired security
 groups and neutron will automatically handle this orchestration for you
 (and you don't have to deal with ip_addresses and updates).

 neutron port-create --security-groups group1 network1
 neutron port-create --security-groups group2 network1



 Now #2 handles both allow/deny access as well as provides a potential
 attachment point for other behaviors, *but* you have to know to set up the
 disjoint allocation pools, and your depending on your drivers to handle the
 case of a router that isn't really a router (i.e. it's got two interfaces
 in the same subnet, possibly with the same address (unless you thought of
 that when you set things up)).


 Are you talking about the firewall as a service stuff here?


  You can say that both of these are *possible*, but they both look
 more complex to me than just having two groups of ports and specifying a
 policy between them.


  Would you mind proposing how this is done in the Group policy api? From
 what I can tell in the new proposed api you'd need to map both of these
 groups to different endpoints i.e networks.



 Ryan Moats


 Best,

 Aaron

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 APIs. Under this light, it's not going to look like there
is a point to this code being in Neutron since, as you said, the
abstraction could happen at a client. However, this changes once new
mapping drivers can be added that implement things differently.

Let's take the security groups example. Using the security groups API
directly is imperative (put a firewall rule on this port that blocks
this IP) compared to a higher level declarative abstraction (make sure
these two endpoints cannot communicate). With the former, the ports
must support security groups and there is nowhere except for the
firewall rules on that port to implement it without violating the user's
expectation. 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 improvement and works with ports that don't support
security groups.

Group based policy is trying to move the requests into the declarative
abstraction so optimizations like the one above can be made.


So, in short, GBP is an effort to provide an API that substitutes 
generic names for specific names in order to allow custom proprietary 
hardware vendors to wire in their hardware using an API that better 
matches their own internal modelling.


Would that be a good statement of the end-goal of GBP?

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 implementation with the existing
 APIs. Under this light, it's not going to look like there is a point to this
 code being in Neutron since, as you said, the abstraction could happen at a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


Kevin, you have captured the GBP value prop and difference very
succinctly. The major difference is in the declarative (GBP) versus
imperative (current) style of programming.

This has been stated very clearly and explicitly in the blueprint
spec. If one does not appreciate the difference or advantage of one
over the other, then this discussion is pointless.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-06 Thread Aaron Rosen
On Wed, Aug 6, 2014 at 12:45 PM, Ryan Moats rmo...@us.ibm.com wrote:

 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 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 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 same IP subnet (an example of this is a bump-in-the-
  wire network appliance).

  Would you mind explaining what behavior you want between the two
  collection of ports?

 That's the point - I want a framework that will work regardless of the
 specifics of the behavior later on.


  I've looked around regular Neutron and all I've come up with so far is:
  (1) use security groups on the ports
  (2) set allow_overlapping_ips to true, set up two networks with
  identical CIDR block subnets and disjoint allocation pools and put a
  vRouter between them.
 
  Now #1 only works for basic allow/deny access and adds the
  complexity of needing to specify per-IP address security rules,
  which means you need the ports to have IP addresses already and then
  manually add them into the security groups, which doesn't seem
  particularly very orchestration friendly.
 
  I believe the referential security group rules solve this problem
  (unless I'm not understanding):
 
  neutron security-group-create group1
  neutron security-group-create group2
 
  # allow members of group1 to ssh into group2 (but not the other way
 around):
  neutron security-group-rule-create --direction ingress --port-range-
  min 22 --port-range-max 22 --protocol TCP --remote-group-id group1 group2
 
  # allow members of group2 to be able to access TCP 80 from members
  of group1 (but not the other way around):
  neutron security-group-rule-create --direction ingress --port-range-
  min 80 --port-range-max 80 --protocol TCP --remote-group-id group2 group1
 
  # Now when you create ports just place these in the desired security
  groups and neutron will automatically handle this orchestration for
  you (and you don't have to deal with ip_addresses and updates).
 
  neutron port-create --security-groups group1 network1
  neutron port-create --security-groups group2 network1

 While those rule instances aren't particularly interesting, I concede that
 security groups can handle allow/deny. However, allow/deny is the least
 interesting part of the problem :)


  Now #2 handles both allow/deny access as well as provides a
  potential attachment point for other behaviors, *but* you have to
  know to set up the disjoint allocation pools, and your depending on
  your drivers to handle the case of a router that isn't really a
  router (i.e. it's got two interfaces in the same subnet, possibly
  with the same address (unless you thought of that when you set things
 up)).

  Are you talking about the firewall as a service stuff here?

 No, I'm being more general than any of the curret *aaS items, I'm thinking
 of the general service insertion case.


  You can say that both of these are *possible*, but they both look
  more complex to me than just having two groups of ports and
  specifying a policy between them.
 
  Would you mind proposing how this is done in the Group policy api?
  From what I can tell in the new proposed api you'd need to map both
  of these groups to different endpoints i.e networks.

 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 can
 specify endpoint-group on port create

 neutron grouppolicy-endpoint-group-create group1
 neutron grouppolicy-endpoint-group-create group2


 neutron port-create --endpoint-group group1 network1
 neutron port-create --endpoint-group group2 network1


Sorry, I don't follow what this port-create command does? Here ---
https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
 --- shows that endpoint-groups map to networks so i'm confused why
network1 is coming into play here?



 neutron grouppolicy-policy-action-create action
 neutron grouppolicy-policy-classifier-create classifier
 neutron grouppolicy-policy-rule-create --action action --classifier
 classifer rule
 neutron policy-apply rule group1 group2


Mind mapping this to my example so we can see how to achieve the same thing
in group policy (with protocols and all)?  Looks like you would also need
to specify

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
driver implements things for the reference implementation with the existing
APIs. Under this light, it's not going to look like there is a point to this
code being in Neutron since, as you said, the abstraction could happen at a
client. However, this changes once new mapping drivers can be added that
implement things differently.

Let's take the security groups example. Using the security groups API
directly is imperative (put a firewall rule on this port that blocks this
IP) compared to a higher level declarative abstraction (make sure these
two endpoints cannot communicate). With the former, the ports must support
security groups and there is nowhere except for the firewall rules on that
port to implement it without violating the user's expectation. 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 improvement and
works with ports that don't support security groups.

Group based policy is trying to move the requests into the declarative
abstraction so optimizations like the one above can be made.



Kevin, you have captured the GBP value prop and difference very
succinctly. The major difference is in the declarative (GBP) versus
imperative (current) style of programming.

This has been stated very clearly and explicitly in the blueprint
spec. If one does not appreciate the difference or advantage of one
over the other, then this discussion is pointless.


One does appreciate the value of having porcelain APIs overlay a 
plumbing API. This discussion was about the proper way and place to 
introduce such functionality.


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 spoke proprietary device APIs.


If this is the end-goal, it should be stated more clearly, IMO.

The classic plumbing versus porcelain API conversation [1] is a good 
one, and one worth having in the context of Neutron.


It's almost like some Neutron contributor folks are saying let's add a 
porcelain API so we can ditch all the existing plumbing APIs and replace 
with our own stuff. And that's not what the point of plumbing vs. 
porcelain is.


-jay

[1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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 APIs. Under this light, it's not going to look like there
  is a point to this code being in Neutron since, as you said, the
  abstraction could happen at a client. However, this changes once new
  mapping drivers can be added that implement things differently.
 
  Let's take the security groups example. Using the security groups API
  directly is imperative (put a firewall rule on this port that blocks
  this IP) compared to a higher level declarative abstraction (make
sure
  these two endpoints cannot communicate). With the former, the ports
  must support security groups and there is nowhere except for the
  firewall rules on that port to implement it without violating the
user's
  expectation. 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 improvement and works with ports that don't support
  security groups.
 
  Group based policy is trying to move the requests into the declarative
  abstraction so optimizations like the one above can be made.

 So, in short, GBP is an effort to provide an API that substitutes
 generic names for specific names in order to allow custom proprietary
 hardware vendors to wire in their hardware using an API that better
 matches their own internal modelling.

 Would that be a good statement of the end-goal of GBP?


No. That would be incorrect.
If you have the time, please see the following article. Even though it is
more than a year old, it may help in clarifying the intent of the policy
work.

M. Banikazemi, D, Olshefski, A. Shaikh, J. Tracey, G. Wang, Meridian: an
SDN platform for cloud network services, IEEE Communications Magazine,
vol. 51, no. 2, February 2013

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=truearnumber=6461196

Best,

-Mohammad


 -jay

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 hardware vendors.

We don't use SQL because Oracle or Microsoft have good optimizations. We
use it because it lets people say what they want without worrying about how
it happens.


On Wed, Aug 6, 2014 at 2: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 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 like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen
 at a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.


 One does appreciate the value of having porcelain APIs overlay a
 plumbing API. This discussion was about the proper way and place to
 introduce such functionality.

 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 spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.

 The classic plumbing versus porcelain API conversation [1] is a good one,
 and one worth having in the context of Neutron.

 It's almost like some Neutron contributor folks are saying let's add a
 porcelain API so we can ditch all the existing plumbing APIs and replace
 with our own stuff. And that's not what the point of plumbing vs.
 porcelain is.

 -jay

 [1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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 like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen at
 a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.


 One does appreciate the value of having porcelain APIs overlay a plumbing
 API. This discussion was about the proper way and place to introduce such
 functionality.

 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 spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.


The goal and design intent is unambiguously stated in the spec [1];

L36-L38
The policy framework described in this blueprint complements the current
Neutron model with the notion of policies that can be applied between
groups of endpoints.

Note the choice of words - complements. The implementation also has
been faithful to this intent.

I am not sure why you would draw the conclusion that you did.

[1] 
https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm

 The classic plumbing versus porcelain API conversation [1] is a good one,
 and one worth having in the context of Neutron.

 It's almost like some Neutron contributor folks are saying let's add a
 porcelain API so we can ditch all the existing plumbing APIs and replace
 with our own stuff. And that's not what the point of plumbing vs. porcelain
 is.

 -jay

 [1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 
 drivers that spoke proprietary device APIs.
 
 If this is the end-goal, it should be stated more clearly, IMO.

I believe that people should be considered innocent until proven otherwise. Is 
there a reason to believe there is some hidden reason behind this proposal ? It 
seems to me that this is uncalled for.

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 was their intent. As far as i know most plugins talk to a 
proprietary API.

I happen to disagree technically with a couple of choices made by this 
proposal; but the blueprint was approved. Which means that i lost the argument, 
or didn't raise it on time, or didn't argue convincingly... regardless of the 
reason, the time to argue about the goal has passed. The decision of the 
community was to approve the spec and that decision should be respected.

  Pedro.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 reference implementation in neutron for declarative model in neutron and
vendors can substitute their implementation to enhance what is in
reference.

But what you need to understand is the declarative model that it provides
which Ryan has elaborated which current neutron does not provide.

prasadv


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 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 like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen
 at a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.


 One does appreciate the value of having porcelain APIs overlay a
 plumbing API. This discussion was about the proper way and place to
 introduce such functionality.

 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 spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.

 The classic plumbing versus porcelain API conversation [1] is a good one,
 and one worth having in the context of Neutron.

 It's almost like some Neutron contributor folks are saying let's add a
 porcelain API so we can ditch all the existing plumbing APIs and replace
 with our own stuff. And that's not what the point of plumbing vs.
 porcelain is.

 -jay

 [1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 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 like there is a point to
this
code being in Neutron since, as you said, the abstraction could happen at
a
client. However, this changes once new mapping drivers can be added that
implement things differently.

Let's take the security groups example. Using the security groups API
directly is imperative (put a firewall rule on this port that blocks
this
IP) compared to a higher level declarative abstraction (make sure these
two endpoints cannot communicate). With the former, the ports must
support
security groups and there is nowhere except for the firewall rules on
that
port to implement it without violating the user's expectation. 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 improvement and
works with ports that don't support security groups.

Group based policy is trying to move the requests into the declarative
abstraction so optimizations like the one above can be made.



Kevin, you have captured the GBP value prop and difference very
succinctly. The major difference is in the declarative (GBP) versus
imperative (current) style of programming.

This has been stated very clearly and explicitly in the blueprint
spec. If one does not appreciate the difference or advantage of one
over the other, then this discussion is pointless.



One does appreciate the value of having porcelain APIs overlay a plumbing
API. This discussion was about the proper way and place to introduce such
functionality.

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 spoke proprietary device APIs.

If this is the end-goal, it should be stated more clearly, IMO.



The goal and design intent is unambiguously stated in the spec [1];

L36-L38
The policy framework described in this blueprint complements the current
Neutron model with the notion of policies that can be applied between
groups of endpoints.

Note the choice of words - complements. The implementation also has
been faithful to this intent.

I am not sure why you would draw the conclusion that you did.

[1] 
https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm


OK, cool. Then it seems to me that would be a perfect justification for 
having this code and API live outside of the Neutron tree, then?


In other words, what benefit does having the GBP code in the Neutron 
codebase give us?


-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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 implementation with the
 existing
 APIs. Under this light, it's not going to look like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen
 at
 a
 client. However, this changes once new mapping drivers can be added
 that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure
 these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. 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 improvement
 and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.



 One does appreciate the value of having porcelain APIs overlay a
 plumbing
 API. This discussion was about the proper way and place to introduce such
 functionality.

 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 spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.


 The goal and design intent is unambiguously stated in the spec [1];

 L36-L38
 The policy framework described in this blueprint complements the current
 Neutron model with the notion of policies that can be applied between
 groups of endpoints.

 Note the choice of words - complements. The implementation also has
 been faithful to this intent.

 I am not sure why you would draw the conclusion that you did.

 [1]
 https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm


 OK, cool. Then it seems to me that would be a perfect justification for
 having this code and API live outside of the Neutron tree, then?

 In other words, what benefit does having the GBP code in the Neutron
 codebase give us?


And for that I would again request that you look at the following
stated in the blueprint spec ;-):

L43-48
This proposal suggests a model that allows application administrators to
express their networking requirements using group and policy
abstractions, with the specifics of policy enforcement and
implementation left to the underlying policy driver. The main
advantage of the extensions described in this blueprint is that they
allow for an application-centric interface to Neutron that complements
the existing network-centric interface.

L52-78 also spell out some of the details of these claims.


 -jay


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 in that respect does not change. There
is a reference implementation in neutron for declarative model in
neutron and vendors can substitute their implementation to enhance what
is in reference.

But what you need to understand is the declarative model that it
provides which Ryan has elaborated which current neutron does not provide.


Why can't it live outside of the Neutron tree?

-jay


On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com
mailto: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
mailto: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 implementation
with the existing
APIs. Under this light, it's not going to look like there is
a point to this
code being in Neutron since, as you said, the abstraction
could happen at a
client. However, this changes once new mapping drivers can
be added that
implement things differently.

Let's take the security groups example. Using the security
groups API
directly is imperative (put a firewall rule on this port
that blocks this
IP) compared to a higher level declarative abstraction
(make sure these
two endpoints cannot communicate). With the former, the
ports must support
security groups and there is nowhere except for the firewall
rules on that
port to implement it without violating the user's
expectation. 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
improvement and
works with ports that don't support security groups.

Group based policy is trying to move the requests into the
declarative
abstraction so optimizations like the one above can be made.


Kevin, you have captured the GBP value prop and difference very
succinctly. The major difference is in the declarative (GBP) versus
imperative (current) style of programming.

This has been stated very clearly and explicitly in the blueprint
spec. If one does not appreciate the difference or advantage of one
over the other, then this discussion is pointless.


One does appreciate the value of having porcelain APIs overlay a
plumbing API. This discussion was about the proper way and place to
introduce such functionality.

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 spoke proprietary device
APIs.

If this is the end-goal, it should be stated more clearly, IMO.

The classic plumbing versus porcelain API conversation [1] is a good
one, and one worth having in the context of Neutron.

It's almost like some Neutron contributor folks are saying let's
add a porcelain API so we can ditch all the existing plumbing APIs
and replace with our own stuff. And that's not what the point of
plumbing vs. porcelain is.

-jay

[1]
http://git-scm.com/book/en/__Git-Internals-Plumbing-and-__Porcelain
http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain


_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 I know) that I
 can specify endpoint-group on port create

 neutron grouppolicy-endpoint-group-create group1
 neutron grouppolicy-endpoint-group-create group2

 neutron port-create --endpoint-group group1 network1
 neutron port-create --endpoint-group group2 network1

 Sorry, I don't follow what this port-create command does? Here ---
 https://docs.google.com/presentation/d/

1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
  --- shows that endpoint-groups map to networks so i'm confused why
 network1 is coming into play here?

Let's be careful that we aren't mixing concepts. First, this is where I
said I'm going to assume I can do this above comes in and so the network
applies to the port-create, not to the group.

Second, the mapping you site is optional and a subtle point is that while
a group maps to a multiplicity of subnets, those subnets can themselves be
in different networks, so a group does not automatically equate to a
network.

 neutron grouppolicy-policy-action-create action
 neutron grouppolicy-policy-classifier-create classifier
 neutron grouppolicy-policy-rule-create --action action --classifier
 classifer rule
 neutron policy-apply rule group1 group2

 Mind mapping this to my example so we can see how to achieve the
 same thing in group policy (with protocols and all)?  Looks like you
 would also need to specify (--provided-contracts, --consumed-
 contracts) when you create the endpoint-groups. Also, I don't see a
 cli command policy-apply so i'm not sure really what that does.

This is where I invoke my I'm a fan of the 2-group approach statement
above.
This is my proposed shorthand for the following three commands:

neutron grouppolicy-contract-create --poilcy-rule rule contract
neutron grouppolicy-endpoint-group-update --provides-contract contract
group2
neutron grouppolicy-endpoint-group-update --consumes-contract contract
group1

see:
http://lists.openstack.org/pipermail/openstack-dev/2014-July/041467.html

 One major difference between GP and current neutron (other than
 security groups) is in your last statement about tying things to
 networks.  Like security groups, groups in GP can have ports that
 span networks.

 So are you saying that group policy doesn't allow us to do different
 enforcement points on the same network as we do today?

That was not my intent.  I was only trying to point out that these groups
(like security groups) are not scoped by networks.

  Unlike security groups, GP allows more rich policy than just allow.

 Right - I can see that GP does provide an allow/deny construct,
 though as you pointed out we can extend the current security group
 concept in neutron to provide allow/deny semantics to achieve the
 same thing no?

My only comments is that GP has been in the pipeline longer that the BP I
cite below...

 That of course begs the question of extending security groups (think
 this blueprint https://review.openstack.org/#/c/93112/ ) but that
 approach may have its own issues.___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 was their intent.
As far as i know most plugins talk to a proprietary API.

I happen to disagree technically with a couple of choices made by
this proposal; but the blueprint was approved. Which means that i
lost the argument, or didn't raise it on time, or didn't argue
convincingly... regardless of the reason, the time to argue about the
goal has passed. The decision of the community was to approve the
spec and that decision should be respected.


Sure, no problem. I'll just go back to Nova and wait around to help 
clean up the mess.


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.


Neutron contributors need to recognize that Nova is the pre-eminent 
consumer of Neutron interfaces, and until those interfaces are stable, 
consistent regardless of underlying hardware or driver choices, and 
generally preferable for Nova to recommend as its default network 
driver, then the Neutron project is sitting as an island unto itself.


The fact that not enough Nova developers (including yours truly) are 
paying attention to what is going on in Neutron spec-land and roadmap is 
a serious problem we should deal with directly (cross-project spec 
meetings, better documentation and communication, shared bug triaging 
and verification meetings, etc). Otherwise, these kinds of conversations 
are likely to continue.


Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 haven't seen any evidence that ongoing development of this new API
is preventing any of the parity work from happening. Nobody is advocating
that the parity work be delayed because of this. We are all aware of the
threats the TC has put forth with regard to demoting Neutron to incubation
unless the parity demands are met. If you want ongoing development to stop,
this should be a clear requirement and it should be evenly applied to all
work (LBaaS separation, ML2 enhancements, any third party drivers, etc).



On Wed, Aug 6, 2014 at 3:10 PM, Jay Pipes jaypi...@gmail.com wrote:

 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 was their intent.
 As far as i know most plugins talk to a proprietary API.

 I happen to disagree technically with a couple of choices made by
 this proposal; but the blueprint was approved. Which means that i
 lost the argument, or didn't raise it on time, or didn't argue
 convincingly... regardless of the reason, the time to argue about the
 goal has passed. The decision of the community was to approve the
 spec and that decision should be respected.


 Sure, no problem. I'll just go back to Nova and wait around to help clean
 up the mess.

 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.

 Neutron contributors need to recognize that Nova is the pre-eminent
 consumer of Neutron interfaces, and until those interfaces are stable,
 consistent regardless of underlying hardware or driver choices, and
 generally preferable for Nova to recommend as its default network driver,
 then the Neutron project is sitting as an island unto itself.

 The fact that not enough Nova developers (including yours truly) are
 paying attention to what is going on in Neutron spec-land and roadmap is a
 serious problem we should deal with directly (cross-project spec meetings,
 better documentation and communication, shared bug triaging and
 verification meetings, etc). Otherwise, these kinds of conversations are
 likely to continue.

 Best,
 -jay


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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 haven't seen any evidence that ongoing development of this new
 API is preventing any of the parity work from happening. Nobody is
 advocating that the parity work be delayed because of this. We are all
 aware of the threats the TC has put forth with regard to demoting Neutron
 to incubation unless the parity demands are met. If you want ongoing
 development to stop, this should be a clear requirement and it should be
 evenly applied to all work (LBaaS separation, ML2 enhancements, any third
 party drivers, etc).



 On Wed, Aug 6, 2014 at 3:10 PM, Jay Pipes jaypi...@gmail.com wrote:

 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 was their intent.
 As far as i know most plugins talk to a proprietary API.

 I happen to disagree technically with a couple of choices made by
 this proposal; but the blueprint was approved. Which means that i
 lost the argument, or didn't raise it on time, or didn't argue
 convincingly... regardless of the reason, the time to argue about the
 goal has passed. The decision of the community was to approve the
 spec and that decision should be respected.


 Sure, no problem. I'll just go back to Nova and wait around to help clean
 up the mess.

 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.

 Neutron contributors need to recognize that Nova is the pre-eminent
 consumer of Neutron interfaces, and until those interfaces are stable,
 consistent regardless of underlying hardware or driver choices, and
 generally preferable for Nova to recommend as its default network driver,
 then the Neutron project is sitting as an island unto itself.

 The fact that not enough Nova developers (including yours truly) are
 paying attention to what is going on in Neutron spec-land and roadmap is a
 serious problem we should deal with directly (cross-project spec meetings,
 better documentation and communication, shared bug triaging and
 verification meetings, etc). Otherwise, these kinds of conversations are
 likely to continue.

 Best,
 -jay


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Kevin Benton

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


Hi Kevin,

Interesting points. Though, let me ask this. Why do we need to move to a
declarative API abstraction in neutron in order to perform this
optimization on the backend? For example, In the current neutron model say
we want to create a port with a security group attached to it called web
that allows TCP:80 in and members who are in a security group called
database. From this mapping I fail to see how it's really any different
from the declarative model? The ports in neutron are logical abstractions
and the backend system could be implemented in order to determine that the
communication between these two hosts could be prevented by using an ACL on
a router or switch as well.

Best,

Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that allows TCP:80 in and members who are in a security group called
 database. From this mapping I fail to see how it's really any different
 from the declarative model? The ports in neutron are logical abstractions
 and the backend system could be implemented in order to determine that the
 communication between these two hosts could be prevented by using an ACL on
 a router or switch as well.

 Best,

 Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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?);
- We make GBP a stackforge project, that integrates with Neutron in some
shape or form;

Another option, might be something in between, where GBP is in tree, but in
some sort of experimental staging area (even though I am not sure how well
baked this idea is).

Now, as a community we all need make a decision; arguing about the fact
that the blueprint was approved is pointless. As a matter of fact, I think
that blueprint should be approved, if and only if the code has landed
completely, but I digress!

Let's together come up with pros and cons of each approach and come up with
an informed decision.

Just reading free form text, how are we expected to do that? At least I
can't!

My 2c.
Armando


On 6 August 2014 15:03, Aaron Rosen aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that allows TCP:80 in and members who are in a security group called
 database. From this mapping I fail to see how it's really any different
 from the declarative model? The ports in neutron are logical abstractions
 and the backend system could be implemented in order to determine that the
 communication between these two hosts could be prevented by using an ACL on
 a router or switch as well.

 Best,

 Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 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 make GBP a stackforge project, that integrates with Neutron in some
 shape or form;

 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).

 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless. As a matter of fact, I think
 that blueprint should be approved, if and only if the code has landed
 completely, but I digress!

 Let's together come up with pros and cons of each approach and come up
 with an informed decision.

 Just reading free form text, how are we expected to do that? At least I
 can't!

 My 2c.
 Armando


 On 6 August 2014 15:03, Aaron Rosen aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that allows TCP:80 in and members who are in a security group called
 database. From this mapping I fail to see how it's really any different
 from the declarative model? The ports in neutron are logical abstractions
 and the backend system could be implemented in order to determine that the
 communication between these two hosts could be prevented by using an ACL on
 a router or switch as well.

 Best,

 Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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
 '/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 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 make GBP a stackforge project, that integrates with Neutron in some
 shape or form;

 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).

 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless. As a matter of fact, I think
 that blueprint should be approved, if and only if the code has landed
 completely, but I digress!

 Let's together come up with pros and cons of each approach and come up
 with an informed decision.

 Just reading free form text, how are we expected to do that? At least I
 can't!

 My 2c.
 Armando


 On 6 August 2014 15:03, Aaron Rosen aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers 
 can
 be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this optimization
 on the backend? For example, In the current neutron model say we want to
 create a port with a security group attached to it called web that allows
 TCP:80 in and members who are in a security group called database. From this
 mapping I fail to see how it's really any different from the declarative
 model? The ports in neutron are logical abstractions and the backend system
 could be implemented in order to determine that the communication between
 these two hosts could be prevented by using an ACL on a router or switch as
 well.

 Best,

 Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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
- immediate delivery vehicle for consumption by operators
  - cons
- code is burder from a number of standpoints (review, test, etc)

Option 2:
  - pros
- enable a small set of Illuminati to iterate faster
  - cons
- integration burden with other OpenStack projects (keystone, nova,
neutron, etc)

Cheers,
Armando
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 to support security groups.



Lets take this example where we setup a 2 tier app with web-servers and
db-servers that are connected on two different networks attached to a
router. We add a security group rules such that web-servers can talk to
db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
anywhere.

neutron net-create web_net
neutron subnet-create --name web_subnet web_net 10.0.0.0/24

neutron net-create db_net
neutron subnet-create --name db_subnet db_net 10.2.0.0/24

neutron router-create myrouter
neutron router-interface-add myrouter web_subnet
neutron router-interface-add myrouter db_subnet

neutron security-group-create  web-servers;
neutron security-group-create db-servers;

# add rule to allow web members to talk to the db-servers on TCP 3306 for
their db connection;
neutron security-group-rule-create --protocol TCP --port-range-min 3306
--port-range-max 3306 --remote-group-id web-servers db-servers

# add rule to allow TCP 80 into the web-server sg
neutron security-group-rule-create --protocol TCP --port-range-min 80
--port-range-max 80 web-servers db-servers

# create some ports with desired security profiles.
neutron port-create  --security-group web-servers web_net
neutron port-create  --security-group web-servers web_net

neutron port-create  --security-group db-servers db_net
neutron port-create  --security-group db-servers db_net


Now to your point:

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.


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. The backend system should have the full graph of
everything and be able to do enforcement optimizations where ever it likes.

btw: I say the enforcement could be done on the logical router though the
backend system could also do this on the physical fabic as well if it
wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that allows TCP:80 in and members who are in a security group called
 database. From this mapping I fail to see how it's really any different
 from the declarative model? The ports in neutron are logical abstractions
 and the backend system could be implemented in order to determine that the
 communication between these two hosts could be prevented by using an ACL on
 a router or switch as well.

 Best,

 Aaron



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 

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, load
balancer, etc. add something that will be run alongside the core API.
This service plugin instead define a different kind of abstractive
(declarative vs imperative as it has been mentioned several times) and it
won't be wrong to say it can replace the core API. To this aim I think it's
fair to consider it an experimentation around a new tenant API.

In this hypothesis, how should this be treated? The decision ultimately
does not lie with me.
I would merely point out that:
1) The neutron core team should not stop innovation. If a consistent part
of the community feels that a declarative base model is that way forward
and we should experiment with it, than we should do everything we can to
help this part of the community.
2) On the other hand, innovation and experimentation should not deprive the
core team of significant resources which should be directed first and
foremost to address the areas identified by the TC as in need of improvement
In the light of the above, and reflecting on the ultimate question which is
whether this code should be merged or not. Allow me to say that my final
thought is that I don't care whether is merged in the main neutron repo or
somewhere else, as long as it does not constitute additional burden for the
core team in terms of reviews, maintainability, gate failures (it won't be
the first time I or other core team members had to chase failures for some
service plugins digging into logs), and future design decisions (ie: having
to ask the question - what about group policy for every future API
decision)

Salvatore

PS: did I make post #100?



On 7 August 2014 00: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/'
  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 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 make GBP a stackforge project, that integrates with Neutron in some
 shape or form;

 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).

 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless. As a matter of fact, I think
 that blueprint should be approved, if and only if the code has landed
 completely, but I digress!

 Let's together come up with pros and cons of each approach and come up
 with an informed decision.

 Just reading free form text, how are we expected to do that? At least I
 can't!

 My 2c.
 Armando


 On 6 August 2014 15:03, Aaron Rosen aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that 

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 addresses. If
you tried to enforce this at the router you would be violating that
specification because devices in the same subnet would be able to
communicate on those blocked ports.


On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the current neutron model say
 we want to create a port with a security group attached to it called web
 that allows TCP:80 in and members who are in a security group called
 database. From this mapping I fail to see how it's 

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 pros and cons exactly, If I am ask?
 
 Let me start:
 
 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators

Since our collective goal is to maximize the benefits for OpenStack 
users/operators, that seems to be the winner.

   - cons
 - code is burder from a number of standpoints (review, test, etc)

Any piece of code is a burden.

 
 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster

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 in terms of support 
(from multiple different organizations) and that the team has put a non trivial 
effort in making the effort public. I don't think we can characterize the team 
either as a secret group or a small set.

  Pedro.

  
   - cons
 - integration burden with other OpenStack projects (keystone, nova, 
 neutron, etc)
 
 Cheers,
 Armando
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?


[1] - 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
improvement and works with ports that don't support security groups.

states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it 

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 in
 terms of support (from multiple different organizations) and that the team
 has put a non trivial effort in making the effort public. I don't think we
 can characterize the team either as a secret group or a small set.


You misread me completely, please refrain from making these comments: I
deride no-one.

I chose the word in reference to the Enlightenment movement, with emphasis
to breaking the traditional way of thinking (declarative vs imperative),
and I found that the analogy would stick, but apparently not.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 the security group.


On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 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 contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your enforcement. If
 the backend system chooses to implement this optimization in this fashion
 (which was the example you gave previously [1]). Then, if the topology
 changes, i.e adding a port to the same network with conflicting security
 group rules, the backend system can no longer optimize in this same fashion
 at the router level and a more fine grain filtering will need to be done.
 How would this be any different with group based policy?


 [1] - 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
 improvement and works with ports that don't support security groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though
 the backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with 
 the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things 

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
 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 addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?

[1] - 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
improvement and works with ports that don't support security groups.



 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups and there is 

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 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 addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?

[1] - 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
improvement and works with ports that don't support security groups.





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups 

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 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 addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.



Sure, though this is a problem of where you are doing your enforcement. If
the backend system chooses to implement this optimization in this fashion
(which was the example you gave previously [1]). Then, if the topology
changes, i.e adding a port to the same network with conflicting security
group rules, the backend system can no longer optimize in this same fashion
at the router level and a more fine grain filtering will need to be done.
How would this be any different with group based policy?

[1] - 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
improvement and works with ports that don't support security groups.




 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306 for
 their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though the
 backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups 

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 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 contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.



 Sure, though this is a problem of where you are doing your enforcement. If
 the backend system chooses to implement this optimization in this fashion
 (which was the example you gave previously [1]). Then, if the topology
 changes, i.e adding a port to the same network with conflicting security
 group rules, the backend system can no longer optimize in this same fashion
 at the router level and a more fine grain filtering will need to be done.
 How would this be any different with group based policy?

 [1] - 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
 improvement and works with ports that don't support security groups.




 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though
 the backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the reference implementation with 
 the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on 

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 plugin, are
 quite different from the ones we have now. Things like firewall, load
 balancer, etc. add something that will be run alongside the core API.
 This service plugin instead define a different kind of abstractive
 (declarative vs imperative as it has been mentioned several times) and it
 won't be wrong to say it can replace the core API. To this aim I think it's
 fair to consider it an experimentation around a new tenant API.

 In this hypothesis, how should this be treated? The decision ultimately
 does not lie with me.
 I would merely point out that:
 1) The neutron core team should not stop innovation. If a consistent part
 of the community feels that a declarative base model is that way forward
 and we should experiment with it, than we should do everything we can to
 help this part of the community.
 2) On the other hand, innovation and experimentation should not deprive
 the core team of significant resources which should be directed first and
 foremost to address the areas identified by the TC as in need of improvement
 In the light of the above, and reflecting on the ultimate question which
 is whether this code should be merged or not. Allow me to say that my final
 thought is that I don't care whether is merged in the main neutron repo or
 somewhere else, as long as it does not constitute additional burden for the
 core team in terms of reviews, maintainability, gate failures (it won't be
 the first time I or other core team members had to chase failures for some
 service plugins digging into logs), and future design decisions (ie: having
 to ask the question - what about group policy for every future API
 decision)

 Salvatore

 PS: did I make post #100?



 On 7 August 2014 00: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/'
  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 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 make GBP a stackforge project, that integrates with Neutron in some
 shape or form;

 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).

 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless. As a matter of fact, I think
 that blueprint should be approved, if and only if the code has landed
 completely, but I digress!

 Let's together come up with pros and cons of each approach and come up
 with an informed decision.

 Just reading free form text, how are we expected to do that? At least I
 can't!

 My 2c.
 Armando


 On 6 August 2014 15:03, Aaron Rosen aaronoro...@gmail.com 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 driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers
 can be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must 
 support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. 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 improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to
 a declarative API abstraction in neutron in order to perform this
 optimization on the backend? For example, In the 

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 pedro.r.marq...@gmail.com
wrote:


 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 pros and cons exactly, If I am ask?

 Let me start:

 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators


 Since our collective goal is to maximize the benefits for OpenStack
 users/operators, that seems to be the winner.

   - cons
 - code is burder from a number of standpoints (review, test, etc)


 Any piece of code is a burden.


 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster


 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 in
 terms of support (from multiple different organizations) and that the team
 has put a non trivial effort in making the effort public. I don't think we
 can characterize the team either as a secret group or a small set.

   Pedro.


   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)

 Cheers,
 Armando
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

Mind proposing an alternative example then. The only way I can see this
claim to be made is because Group Based policy is actually limiting what a
tenants desired topology can be?

Thanks,

Aaron



 On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 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 contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your enforcement.
 If the backend system chooses to implement this optimization in this
 fashion (which was the example you gave previously [1]). Then, if the
 topology changes, i.e adding a port to the same network with conflicting
 security group rules, the backend system can no longer optimize in this
 same fashion at the router level and a more fine grain filtering will need
 to be done. How would this be any different with group based policy?


 [1] - 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 improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers and
 db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min 3306
 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it likes.

 btw: I say the enforcement could be done on the logical router though
 the backend system could also do this on the physical fabic as well if it
 wanted to as it should also know that graph. No?



 On Wed, Aug 6, 2014 at 4:03 PM, Aaron Rosen aaronoro...@gmail.com
 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 driver implements things for the 

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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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
 - immediate delivery vehicle for consumption by operators
   - cons
 - code is burder from a number of standpoints (review, test, etc)

 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster
   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)

 Cheers,
 Armando

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 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 pedro.r.marq...@gmail.com
 wrote:


 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 pros and cons exactly, If I am ask?

 Let me start:

 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators


 Since our collective goal is to maximize the benefits for OpenStack
 users/operators, that seems to be the winner.

   - cons
 - code is burder from a number of standpoints (review, test, etc)


 Any piece of code is a burden.


 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster


 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 in
 terms of support (from multiple different organizations) and that the team
 has put a non trivial effort in making the effort public. I don't think we
 can characterize the team either as a secret group or a small set.

   Pedro.


   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)

 Cheers,
 Armando
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 security groups API, you are forcing it to be
implemented there.


On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 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, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



 On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your enforcement.
 If the backend system chooses to implement this optimization in this
 fashion (which was the example you gave previously [1]). Then, if the
 topology changes, i.e adding a port to the same network with conflicting
 security group rules, the backend system can no longer optimize in this
 same fashion at the router level and a more fine grain filtering will need
 to be done. How would this be any different with group based policy?


 [1] - 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 improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers
 and db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers 
 from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min
 3306 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  --security-group db-servers db_net
 neutron port-create  --security-group db-servers db_net


 Now to your point:

 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.


 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. The backend system should have the full graph of
 everything and be able to do enforcement optimizations where ever it 
 likes.

 btw: I say the enforcement could be done on the logical router though
 the backend system could also do this on 

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
with naming which can be cleared fairly quickly


On Wed, Aug 6, 2014 at 4:28 PM, Pedro Marques pedro.r.marq...@gmail.com
wrote:


 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 pros and cons exactly, If I am ask?

 Let me start:

 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators


 Since our collective goal is to maximize the benefits for OpenStack
 users/operators, that seems to be the winner.

   - cons
 - code is burder from a number of standpoints (review, test, etc)


 Any piece of code is a burden.


 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster


 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 in
 terms of support (from multiple different organizations) and that the team
 has put a non trivial effort in making the effort public. I don't think we
 can characterize the team either as a secret group or a small set.

   Pedro.


   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)

 Cheers,
 Armando
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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
 '/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
 - immediate delivery vehicle for consumption by operators


Buried inside these 100+ posts are posts from two OpenStack users
pleading for their desire to use GBP APIs for their Juno deployments. While
that is a small sample size, it does prove that there is legitimate
interests from our user base to get their hands on this feature.

User feedback is the best way to evolve the APIs moving forward - as
long as these APIs/implementation do not jeopardize the stability of
Neutron. And as many folks in the thread had pointed out, the GBP
implementation currently has really gone the extra mile to ensure it does
NOT do that.



   - cons
 - code is burder from a number of standpoints (review, test, etc)


This is a legitimate concern - that said, if you take a look at the
first patch:

https://review.openstack.org/#/c/95900/

there are 30 human reviewers (non-CI) signed up to review the patch at
this time, and among them 9 Neutron core members (8 if you don't count
Sumit, who is the author), as well as a Nova core. From the reception, I
believe the community does not generally treat reviewing GBP related
patches as a burden, but likely as an item of interest. Additionally, with
such board and strong community base willing to involve in reviewing the
code, I think with these many eyes it will hopefully help lessen the
burden on Neutron cores to review and merge these set of patches.




 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster



As a subgroup, we have already iterated the model and APIs for about a
year, with around 40 IRC meetings for community discussions, a PoC demo
that was presented to about 300 audiences back at J-Summit, and actual
implementations in gerrit for months now. Indeed with about 35+ people
responding to this thread, I have yet to see anyone making a claim that
GBP model and APIs as they are now are crap, we have to scrap it and
rethink. I would like to think that we are at a point where we will do
phase by phase enhancements - as should practically any other APIs in
OpenStack - rather than rapid iterations within a cycle. While we already
have some user feedbacks, we would love to get more and more user and
developer community feedbacks to evolve GBP to better fit their needs, and
stackforge unfortunately does not serve that purpose well.



   - cons
 - integration burden with other OpenStack projects (keystone, nova,
 neutron, etc)



That is indeed a major con - evidenced by the fact that the number of
Nova folks joining the discussion on this thread to express integration
concern. We would like to get GBP integration with other OpenStack projects
done as soon as possible. As you pointed out, stackforge is a terrible
option as it pushes the burden of this integration to much later, which
inevitably will incur much higher integration costs moving forward.

Thanks,
- Stephen




 Cheers,
 Armando

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 either (and I am
sure there many more pros/cons): an immature product is of good use to
no-one, and we still have the nova parity that haunts us.

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.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 like it just incurs
all of the extra overhead of an extra project and doesn't do anything to
improve the parity efforts.


On Wed, Aug 6, 2014 at 7:13 PM, Armando M. arma...@gmail.com wrote:

 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 either
 (and I am sure there many more pros/cons): an immature product is of good
 use to no-one, and we still have the nova parity that haunts us.

 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.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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 showed, or network hardware ACLs like I had shown.
 But if you start with the security groups API, you are forcing it to be
 implemented there.


I still have no idea what group based policy is buying us then. It seems to
me that the key point we've identified going backing and forth here is the
difference between the current model and the GBP model is that GBP
constricts topology which allows us to write these types of enforcement
rules. The reason we want this is because it yields performance
optimizations (for some reason, which I don't think we've gotten into).
Would you agree this is accurate?

Honestly, I know a lot of work has been put into this. I haven't said I'm
for or against it either. I'm really just trying to understand what is the
motivation for this and why does it make neutron better.

Best,

Aaron




 On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com wrote:




 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, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



  On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 contact these
 devices on those ports unless they come from the allowed IP addresses. If
 you tried to enforce this at the router you would be violating that
 specification because devices in the same subnet would be able to
 communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your enforcement.
 If the backend system chooses to implement this optimization in this
 fashion (which was the example you gave previously [1]). Then, if the
 topology changes, i.e adding a port to the same network with conflicting
 security group rules, the backend system can no longer optimize in this
 same fashion at the router level and a more fine grain filtering will need
 to be done. How would this be any different with group based policy?


 [1] - 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 improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers
 and db-servers that are connected on two different networks attached to a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers 
 from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP 3306
 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min
 3306 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min 80
 --port-range-max 80 web-servers db-servers

 # create some ports with desired security profiles.
 neutron port-create  --security-group web-servers web_net
 neutron port-create  --security-group web-servers web_net

 neutron port-create  

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 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 security groups API, you are forcing it to be
 implemented there.


 I still have no idea what group based policy is buying us then. It seems
 to me that the key point we've identified going backing and forth here is
 the difference between the current model and the GBP model is that GBP
 constricts topology which allows us to write these types of enforcement
 rules. The reason we want this is because it yields performance
 optimizations (for some reason, which I don't think we've gotten into).
 Would you agree this is accurate?



Policy framework is a progression towards providing a richer configuration.
Network ACLs help with aggregation (network or other aggregations) and
attaching to broader bind points as opposed to just ports. Giving the
operator a choice of all options is necessary at this point with such
features being standard in public clouds (eg: VPC feature set in AWS)

Rudra



 Aaron




 On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



  On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 contact
 these devices on those ports unless they come from the allowed IP
 addresses. If you tried to enforce this at the router you would be
 violating that specification because devices in the same subnet would be
 able to communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your
 enforcement. If the backend system chooses to implement this optimization
 in this fashion (which was the example you gave previously [1]). Then, if
 the topology changes, i.e adding a port to the same network with
 conflicting security group rules, the backend system can no longer 
 optimize
 in this same fashion at the router level and a more fine grain filtering
 will need to be done. How would this be any different with group based
 policy?


 [1] - 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 improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 to support security groups.



 Lets take this example where we setup a 2 tier app with web-servers
 and db-servers that are connected on two different networks attached to 
 a
 router. We add a security group rules such that web-servers can talk to
 db-servers on tcp:3306 and a rule to allow tcp:80 into the web-servers 
 from
 anywhere.

 neutron net-create web_net
 neutron subnet-create --name web_subnet web_net 10.0.0.0/24

 neutron net-create db_net
 neutron subnet-create --name db_subnet db_net 10.2.0.0/24

 neutron router-create myrouter
 neutron router-interface-add myrouter web_subnet
 neutron router-interface-add myrouter db_subnet

 neutron security-group-create  web-servers;
 neutron security-group-create db-servers;

 # add rule to allow web members to talk to the db-servers on TCP
 3306 for their db connection;
 neutron security-group-rule-create --protocol TCP --port-range-min
 3306 --port-range-max 3306 --remote-group-id web-servers db-servers

 # add rule to allow TCP 80 into the web-server sg
 neutron security-group-rule-create --protocol TCP --port-range-min
 80 

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 and a dash to
make that code stable. The goal is to move quickly to enable replacement of
nova networking.
While group policy is offering additional abstractions which are richer
that enables easier usage of networking.

Both teams have been working diligently towards that goal. As pedro points
out there are several people from different organizations working on GBP to
ensure stability and closely reviewed code is checked in.

I think both nova parity and GBP can go in parallel, hence my choice of
option 1


On Wed, Aug 6, 2014 at 6:13 PM, Armando M. arma...@gmail.com wrote:

 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 either
 (and I am sure there many more pros/cons): an immature product is of good
 use to no-one, and we still have the nova parity that haunts us.

 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.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] 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 strong networking background, and the latter is basically just
stating the requirements and letting Neutron figure out how to implement
it.

Just stating requirements becomes even more important when something like
the logging requirement comes from someone other than the app deployer
(e.g. a security team). In the above example, someone could set everything
up using security groups; however, when the logging requirement came in
from the security team, they would have to undo all of that work and
replace it with something like FWaaS that can centrally log all of the
connections.

It's the difference between using puppet and bash scripts. Sure you can
write a script that uses awk/sed to ensure that an ini file has a
particular setting and then restart a service if the setting is changed,
but it's much easier and less error prone to just write a puppet manifest
that uses the INI module with a pointer to the file, the section name, the
key, and the value with a notification to restart the service.



On Wed, Aug 6, 2014 at 7: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 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 security groups API, you are forcing it to be
 implemented there.


 I still have no idea what group based policy is buying us then. It seems
 to me that the key point we've identified going backing and forth here is
 the difference between the current model and the GBP model is that GBP
 constricts topology which allows us to write these types of enforcement
 rules. The reason we want this is because it yields performance
 optimizations (for some reason, which I don't think we've gotten into).
 Would you agree this is accurate?

 Honestly, I know a lot of work has been put into this. I haven't said I'm
 for or against it either. I'm really just trying to understand what is the
 motivation for this and why does it make neutron better.

 Best,

 Aaron




 On Wed, Aug 6, 2014 at 6:06 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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, it cannot be implemented on the router without violating the
 constraints of the security group.


 Hi Kevin,

 Mind proposing an alternative example then. The only way I can see this
 claim to be made is because Group Based policy is actually limiting what a
 tenants desired topology can be?

 Thanks,

 Aaron



  On Wed, Aug 6, 2014 at 5:39 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:




 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 contact
 these devices on those ports unless they come from the allowed IP
 addresses. If you tried to enforce this at the router you would be
 violating that specification because devices in the same subnet would be
 able to communicate on those blocked ports.


 Sure, though this is a problem of where you are doing your
 enforcement. If the backend system chooses to implement this optimization
 in this fashion (which was the example you gave previously [1]). Then, if
 the topology changes, i.e adding a port to the same network with
 conflicting security group rules, the backend system can no longer 
 optimize
 in this same fashion at the router level and a more fine grain filtering
 will need to be done. How would this be any different with group based
 policy?


 [1] - 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 improvement and works with ports that don't support security
 groups.

 states





 On Wed, Aug 6, 2014 at 5:00 PM, Aaron Rosen aaronoro...@gmail.com
 wrote:


 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 

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

2014-08-06 Thread Alan Kavanagh
+1
I believe Pedro has a very valid point here, and that is the the community to 
approve the spec and that decision should be respected. It makes sense to 
again clearly denote the process and governance and have this noted on the 
thread Stefano started earlier today. 

/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 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 
 drivers that spoke proprietary device APIs.
 
 If this is the end-goal, it should be stated more clearly, IMO.

I believe that people should be considered innocent until proven otherwise. Is 
there a reason to believe there is some hidden reason behind this proposal ? It 
seems to me that this is uncalled for.

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 was their intent. As far as i know most plugins talk to a 
proprietary API.

I happen to disagree technically with a couple of choices made by this 
proposal; but the blueprint was approved. Which means that i lost the argument, 
or didn't raise it on time, or didn't argue convincingly... regardless of the 
reason, the time to argue about the goal has passed. The decision of the 
community was to approve the spec and that decision should be respected.

  Pedro.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev