Open Stack

Howdy!

I have a design question regarding developing an ML2 MechanismDriver to
interface with an external provisioning system. I am assuming that
openstack-devel is an appropriate forum for such discussions until somebody
points me in another direction :-).

Synchronization. OpenStack Networking and an add-on external SDN (etc)
system need to agree on the logical definition of the network. That means
the SDN system's world-view has to match the one in the OpenStack
Networking database tables. The ML2 MechanismDriver is responsible for
ensuring synchronization.

One way to do this is to declare that the SDN system's configuration is
transient. In the event of any synchronization problem (reboot, connection
restart, etc) the full configuration will be transferred from OpenStack to
the SDN system. Then each further change will be sent individually and
asynchronously until the next reboot/reconnect/etc.

My understanding is that the BigSwitch plugin works this way and that the
full network configuration is cached inside the Python process running the
plugin and that this is used for the resynchronization step.

So questions..

Is this a reasonable description of how the BigSwitch plugin works?
Is this a good design?
Is this a reasonable way forward also for other provisioning systems e.g.
Cisco, Brocade, Arista, OpenDaylight, ...?
Or is there a plan to do (say) something transactional with all systems
being persistent master copies?

Cheers!
-Luke



On 5 June 2013 15:44, Kyle Mestery (kmestery) <kmestery at cisco.com> wrote:

>
> On Jun 5, 2013, at 5:11 AM, Luke Gorrie <luke at tail-f.com> wrote:
>
> > Howdy!
> >
> > Great work Bob & all on getting the ML2 plugin code onto master,
> exciting stuff :-)))
> >
> > I want to use the upcoming ML2 MechanismDriver to make REST requests to
> an external system. Is anybody else interested in this too and planning
> related work? If so then perhaps we could join forces.
> >
> > I am flexible with respect to the exact REST API design. In principle I
> would favor something as close as possible to the raw MechanismDriver API.
> >
> > I am doing this work to integrate with the Tail-f Network Control System
> (NCS). The blueprint for this work was approved this morning for Havana.
> https://blueprints.launchpad.net/quantum/+spec/tailf-ncs
> >
> > NCS will be customized to support the REST API that we develop on the
> OpenStack side. So there are no legacy/compatibility constraints on how the
> REST API needs to look from my perspective.
> >
> > I am guessing that the maintainers of the BigSwitch plugin would be
> interested, being as that is also REST-based and may want to be updated to
> fit into ML2?
> >
> > So please give me a ping if you are interested in MechanismDriver+REST,
> or point me at where I can find people who are :-)
> >
> > Cheers,
> > -Luke
> >
> Hi Luke, Bob is organizing some sub team meetings around ML2 going
> forward, we'll be sure to include you in those! Right now, there are 4
> blueprints open for continued ML2 work. I'm not aware of anyone doing a
> controller MechanismDriver yet, so you may have just signed up to be the
> first!
>
> Looking forward to having you a part of the ML2 team!
>
> Kyle
>
> >
> > _______________________________________________
> > 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/20130606/736a9e62/attachment.html>