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

Ryan Moats rmoats at us.ibm.com
Wed Aug 6 21:06:26 UTC 2014


[snipping to save BW]

Aaron Rosen <aaronorosen at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/ab81db98/attachment.html>


More information about the OpenStack-dev mailing list