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 <m...@cgoncalves.pt> wrote: > Hi, > > On 27 May 2014, at 15:55, Mohammad Banikazemi <m...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev