Open Stack

Hi Sumit,

My concern was related to sharing common configuration information not
between GP drivers but configurations between GP and ML2 (and any other
future plugins). When both are enabled, users need to configure drivers
information (e.g., endpoint, username, password) twice, when applicable
(e.g., when using ODL for ML2 and GP). A common configuration file here
could help, yes.

Thanks,
Carlos Goncalves

On Thu, Jun 12, 2014 at 6:05 PM, Sumit Naiksatam <sumitnaiksatam at gmail.com>
wrote:

> 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/d054a692/attachment-0001.html>