OpenStack Quantum Update – what I got wrong and where it’s headed

I’m glad to acknowledge that I incorrectly reported the OpenStack Quantum project would require licensed components for implementation!   I fully stand behind Quantum as being OpenStack’s “killer app” and am happy to post more information about it here.

Side note: My team at Dell is starting to get Crowbar community pings about collaboration on a Quantum barclamp.  Yes, we are interested!

This updates comes via Dan Wendlandt from Nicira who pointed out my error in the Seattle Meetup notes (you can read his comment on that post).  Rather than summarize his information, I’ll let Dan talk for himself…

Dan’s comments about open source Quantum implementation:

There’s a full documentation on how to use Open vSwitch to implement Quantum (see http://docs.openstack.org/incubation/openstack-network/admin/content/ and http://openvswitch.org/openstack/documentation/), and [Dan] even sent a demo link out to the openstack list a while back (http://wiki.openstack.org/QuantumOVSDemo). Open vSwitch is completely open source and free. Some other plugins may require proprietary hardware and/or software, but there is definitely a (very) viable and completely open source option for Quantum networking.

Dan’s comments about Quantum OpenStack project status in the D-E-F release train:

At the end of the Diablo cycle, Quantum applied to become an incubated project, which means it will be incubated for Essex. At the end of the Essex cycle, we plan to apply to be a core project, meaning that if we are accepted, we would be a core project for the F-series release.

Its worth noting, however, that [Dan] knows of many people planning on putting Quantum in production before then, which is the real indicator of a project’s maturity (regardless of whether it is technically “core” or not).