Open Stack

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
>