Open Stack

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