Open Stack

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 <aaronorosen at gmail.com> wrote:

>
>
>
> On Wed, Aug 6, 2014 at 12:25 PM, Ivar Lazzaro <ivarlazzaro at 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 <aaronorosen at gmail.com>
>> wrote:
>>
>>> Hi Ryan,
>>>
>>>
>>> On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats <rmoats at us.ibm.com> wrote:
>>>
>>>> Jay Pipes <jaypipes at 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 at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/688e96e5/attachment.html>