<html><body>
<p><font size="2" face="sans-serif">[snipping to save BW]</font><br>
<br>
<tt><font size="2">Aaron Rosen <aaronorosen@gmail.com> wrote on 08/06/2014 03:26:24 PM:<br>
<br>
> Note: I'm not going to use the pure group policy API as I have been <br>
> a fan of the<br>
> 2-group approach from day 1, I'm going to use the commands as stated<br>
> in the patch set, and I'm going to assume (dangerous I know) that I <br>
> can specify endpoint-group on port create<br>
> <br>
> neutron grouppolicy-endpoint-group-create group1<br>
> neutron grouppolicy-endpoint-group-create group2</font></tt><br>
<tt><font size="2">> <br>
> neutron port-create --endpoint-group group1 network1<br>
> neutron port-create --endpoint-group group2 network1</font></tt><br>
<tt><font size="2">> <br>
> Sorry, I don't follow what this port-create command does? Here --- <br>
> <a href="https://docs.google.com/presentation/d/">https://docs.google.com/presentation/d/</a><br>
> 1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078<br>
> --- shows that endpoint-groups map to networks so i'm confused why <br>
> network1 is coming into play here? </font></tt><br>
<br>
<tt><font size="2">Let's be careful that we aren't mixing concepts. First, this is where I </font></tt><br>
<tt><font size="2">said "I'm going to assume I can do this" above comes in and so the network</font></tt><br>
<tt><font size="2">applies to the port-create, not to the group.</font></tt><br>
<br>
<tt><font size="2">Second, the mapping you site is optional and a subtle point is that while</font></tt><br>
<tt><font size="2">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.</font></tt><br>
<br>
<tt><font size="2">> neutron grouppolicy-policy-action-create action<br>
> neutron grouppolicy-policy-classifier-create classifier<br>
> neutron grouppolicy-policy-rule-create --action action --classifier <br>
> classifer rule<br>
> neutron policy-apply rule group1 group2</font></tt><br>
<tt><font size="2">> <br>
> Mind mapping this to my example so we can see how to achieve the <br>
> same thing in group policy (with protocols and all)? Looks like you<br>
> would also need to specify (--provided-contracts, --consumed-<br>
> contracts) when you create the endpoint-groups. Also, I don't see a <br>
> cli command policy-apply so i'm not sure really what that does.</font></tt><br>
<br>
<tt><font size="2">This is where I invoke my "I'm a fan of the 2-group approach" statement above.</font></tt><br>
<tt><font size="2">This is my proposed shorthand for the following three commands:</font></tt><br>
<br>
<tt><font size="2">neutron grouppolicy-contract-create --poilcy-rule rule contract</font></tt><br>
<tt><font size="2">neutron grouppolicy-endpoint-group-update --provides-contract contract group2</font></tt><br>
<tt><font size="2">neutron grouppolicy-endpoint-group-update --consumes-contract contract group1</font></tt><br>
<br>
<tt><font size="2">see: </font></tt><a href="http://lists.openstack.org/pipermail/openstack-dev/2014-July/041467.html"><tt><font size="2">http://lists.openstack.org/pipermail/openstack-dev/2014-July/041467.html</font></tt></a><br>
<br>
<tt><font size="2">> One major difference between GP and current neutron (other than <br>
> security groups) is in your last statement about tying things to <br>
> networks. Like security groups, groups in GP can have ports that <br>
> span networks.</font></tt><br>
<tt><font size="2">> <br>
> So are you saying that group policy doesn't allow us to do different<br>
> enforcement points on the same network as we do today?</font></tt><br>
<br>
<tt><font size="2">That was not my intent. I was only trying to point out that these groups (like security groups) are not scoped by networks.</font></tt><br>
<br>
<tt><font size="2">> Unlike security groups, GP allows more rich policy than just allow.</font></tt><br>
<tt><font size="2">> <br>
> Right - I can see that GP does provide an allow/deny construct, <br>
> though as you pointed out we can extend the current security group <br>
> concept in neutron to provide allow/deny semantics to achieve the <br>
> same thing no? </font></tt><br>
<br>
<tt><font size="2">My only comments is that GP has been in the pipeline longer that the BP I cite below...</font></tt><br>
<br>
<tt><font size="2">> That of course begs the question of extending security groups (think<br>
> this blueprint https://review.openstack.org/#/c/93112/ ) but that <br>
> approach may have its own issues.<br>
</font></tt></body></html>