[openstack-dev] [neutron][group-based-policy] GP mapping driver

Mohammad Banikazemi mb at us.ibm.com
Fri Jun 13 15:03:06 UTC 2014

I had tried to address the comment on the review board where Carlos had
raised the same issue. Should have posted here as well.


Patch Set 3:
Carlos, The plan is not to have multiple drivers for enforcing policies. At
least not right now. With respect to using same config options by drivers,
we can have a given group policy driver and possibly an ML2 mechanism
driver use the same config namespace. Does this answer your questions?



From:	Sumit Naiksatam <sumitnaiksatam at gmail.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>,
Date:	06/12/2014 01:10 PM
Subject:	Re: [openstack-dev] [neutron][group-based-policy] GP mapping

Hi Carlos,

I noticed that the point you raised here had not been followed up. So
if I understand correctly, your concern is related to sharing common
configuration information between GP drivers, and ML2 mechanism
drivers (when used in the mapping)? If so, would a common
configuration file  shared between the two drivers help to address


On Tue, May 27, 2014 at 10:33 AM, Carlos Gonçalves <mail at cgoncalves.pt>
> Hi,
> On 27 May 2014, at 15:55, Mohammad Banikazemi <mb at us.ibm.com> wrote:
> GP like any other Neutron extension can have different implementations.
> idea has been to have the GP code organized similar to how ML2 and
> drivers are organized, with the possibility of having different drivers
> realizing the GP API. One such driver (analogous to an ML2 mechanism
> I would say) is the mapping driver that was implemented for the PoC. I
> certainly do not see it as the only implementation. The mapping driver is
> just the driver we used for our PoC implementation in order to gain
> experience in developing such a driver. Hope this clarifies things a bit.
> The code organisation adopted to implement the PoC for the GP is indeed
> similar to the one ML2 is using. There is one aspect I think GP will hit
> soon if it continues to follow with its current code base where multiple
> (policy) drivers will be available, and as Mohammad putted it as being
> analogous to an ML2 mech driver, but are independent from ML2’s. I’m
> unaware, however, if the following problem has already been brought to
> discussion or not.
> From here I see the GP effort going, besides from some code refactoring,
> say expanding the supported policy drivers is the next goal. With that
> support might next. Now, administrators enabling GP ODL support will have
> configure ODL data twice (host, user, password) in case they’re using ODL
> a ML2 mech driver too, because policy drivers share no information
> ML2 ones. This can become more troublesome if ML2 is configured to load
> multiple mech drivers.
> With that said, if it makes any sense, a different implementation should
> considered. One that somehow allows mech drivers living in ML2 umbrella
> be extended; BP [1] [2] may be a first step towards that end, I’m
> Thanks,
> Carlos Gonçalves
> [1]

> [2] https://review.openstack.org/#/c/89208/
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/bd3e0cf2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140613/bd3e0cf2/attachment.gif>

More information about the OpenStack-dev mailing list