Open Stack

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

https://review.openstack.org/#/c/96393/

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?

Best,

Mohammad



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
            driver



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
this?

Thanks,
~Sumit.

On Tue, May 27, 2014 at 10:33 AM, Carlos Gonçalves <mail at cgoncalves.pt>
wrote:
> 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.
Our
> idea has been to have the GP code organized similar to how ML2 and
mechanism
> drivers are organized, with the possibility of having different drivers
for
> realizing the GP API. One such driver (analogous to an ML2 mechanism
driver
> 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
very
> 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,
I'd
> say expanding the supported policy drivers is the next goal. With that
ODL
> support might next. Now, administrators enabling GP ODL support will have
to
> configure ODL data twice (host, user, password) in case they’re using ODL
as
> a ML2 mech driver too, because policy drivers share no information
between
> 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
be
> considered. One that somehow allows mech drivers living in ML2 umbrella
to
> be extended; BP [1] [2] may be a first step towards that end, I’m
guessing.
>
> Thanks,
> Carlos Gonçalves
>
> [1]
>
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions

> [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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- 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>