Revision as of 09:45, 14 December 2011

NOTE: this wiki page is acting as a stand-in for real Quantum developer documentation.

If you are trying to enable the use of OpenStack with a new network switching technology, then you probably want to develop a Quantum plugin.

Before you Jump into the Code

Before developing a plugin yourself, make sure you know how Quantum works by reading the Quantum Admin Guide and asking questions.

Then try to run it yourself using devstack

When running from source, be sure you know how to run unit tests, as you'll need to do this before submitting any code:

./run_tests.sh 

Join the netstack team on Launchpad and subscribe to the team email list.

Building a Plugin

What is a Quantum Plugin?

Quantum exposes a logical API to define network connectivity between devices from other OpenStack services (e.g., vNICs from Nova VMs). The logical connectivity described using the API must be translated into actually configuration on virtual and/or physical switches. This is where a Quantum plugin comes in. The Quantum plugin is able to talk to one or more types of switches and dynamically reconfigures the switches based on API calls.

What Code Do I Need to Write

The Quantum code-base has a python API that corresponds to the set of API calls you must implement to be a Quantum plugin. Within the source code directory, look at quantum/quantum_plugin_base.py .

The code-base helps out by providing some useful sqlalchemy bindings to store logical API entities (networks, ports) if you choose to build your plugin around a SQL database.

A plugin usually consists of code to:

• Store information about the current logical network configuration (e.g., a SQL database)
• Determine and store information about the "mapping" of the logical model to the physical network (e.g., picking a VLAN to represent a logical network).
• Communicate with one or more types of switches to configure them according to implement that mapping. This may be in the form of an agent running on the hypervisor, or code that remotely logs into a switch and reconfigures it.

Also, if your switching technology requires nova-compute to create vNICs in a special way, you may need to create a special "vif-plugging" module to be used with your switch. See below for examples.

There should not be a need to modify the QuantumManager code in nova/network/quantum, as this code uses only the logical Quantum API.

Useful Next Steps

• Read the Quantum Overview in the Admin guide to get an understanding of the basic components: http://docs.openstack.org/incubation/openstack-network/admin/content/Overview-d1e369.html
• Browse the Quantum API guide to understand the API that each plugin must implement: http://docs.openstack.org/incubation/openstack-network/developer/quantum-api-1.0/content/
• Get the Quantum code (http://launchpad.net/quantum) and run it according to the admin guide.
• Check out the existing plugins in the quantum/plugins directory to get an idea of what a plugin looks like in practice
• See an example of nova-compute vif-plugging. In the nova codebase, see nova/virt/libvirt/vif.py. The Quantum codebase also include a vif-plug driver that can be used to give nova 802.1qbh capabilities: quantum/plugins/cisco/nova/vif_direct.py
• Join the netstack team on launchpad (http://launchapd.net/~netstack/) and subscribe to the mailing list. You can send more detailed questions about the Quantum code and your plugin development to the team list.

Plugin FAQ

• Q: Can I run multiple plugins at the same time?
• A: No, only a single plugin can be run at a time. That said, this does not mean that you can only talk to one type of switch. One "plugin" can have multiple "drivers" that talk to different types of switches. For example, the Cisco plugin talks to multiple types of switches. There is no formal driver interface, but we encourage people to write the code that talks to a switch in a general way such that other plugins will be able to leverage it. A "driver" will usually be code that is able to talk to a particular switch model or family of switches. "drivers" usually will have methods for standard provisioning operations, like putting a port on a particular VLAN as the result of an attachment.

API Extensions

• Creating Extensions:
  • Extension files should be placed in the extensions folder located at: quantum/extensions .
  • The extension file should have a class with the same name as the filename. This class should implement the contract required by the extension framework. See ExtensionDescriptor class in quantum/common/extensions.py for details.
  • To stop a file in the extensions folder from being loaded as an extension, the filename should start with an "_". For an example of an extension file look at Foxinsocks class in quantum/tests/unit/extensions/foxinsocks.py. The unit tests in server/lib/tests/unit/test_extensions.py document all the ways in which you can use extensions
• Associating plugins with extensions:
  • A Plugin can advertise all the extensions it supports through the 'supported_extension_aliases' attribute. Eg:

      class SomePlugin:
        ...
        supported_extension_aliases = ['extension1_alias',
                                     'extension2_alias',
                                     'extension3_alias']
      Any extension not in this list will not be loaded for the plugin

• Extension Interfaces for plugins (optional). The extension can mandate an interface that plugins have to support with the 'get_plugin_interface' method in the extension. For an example see the FoxInSocksPluginInterface in foxinsocks.py. The QuantumEchoPlugin lists foxinsox in its supported_extension_aliases and implements the method from FoxInSocksPluginInterface.

Quantum Packaging Code

At least for the short-term, Quantum includes code in the source directory to build packages for wider distribution. Use the following commands:

For Red Hat RPMs:

python setup.py build rpm

For Debian debs (requires building RPMs first):

python setup.py build deb