Open Stack

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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140527/41989b14/attachment.html>