[Netstack] support for multiple plugins in Quantum
Hi, I am working on a Quantum plugin for Brocade switches. I noticed that if multiple 'provider' lines are specified in quantum/plugins.ini that quantum will use the last one and ignore the rest. What are the plans to support networking equipment from multiple vendors within openstack? Seems to me there needs to be a resource pool for switches, and when nova decides which compute node will host the VM, then 1 of the switches (maybe only 1) that is physically attached to that compute node is selected by quantum. Then the plugin for that switch is loaded (if it isn't already), and the plugin uses the switch(es) and port(s) that quantum tells it to use. Andy -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] support for multiple plugins in Quantum
Currently, the one and only plugin selected is clearly not going to support all possible driver types. It will support 1 or more switch types by a specific vendor. So it seems that Quantum developer API needs to move down a layer, so the one-and-only-plugin can talk to any driver type. Then drivers get registered in plugins.ini, not the q-plugin. I have been implementing a separate wrapper and driver, and following the return data in the openvswitch and cisco drivers (not the API docs). I like the idea of a common plugin that manages the global data structures, and handles the task list you described, and using a new API for drivers instead. Andy From: Dan Wendlandt [mailto:d...@nicira.com] Sent: Tuesday, September 20, 2011 12:10 PM To: Andy Bierman Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] support for multiple plugins in Quantum On Tue, Sep 20, 2011 at 11:53 AM, Andy Bierman mailto:bierm...@brocade.com>> wrote: Hi, I am working on a Quantum plugin for Brocade switches. I noticed that if multiple 'provider' lines are specified in quantum/plugins.ini that quantum will use the last one and ignore the rest. What are the plans to support networking equipment from multiple vendors within openstack? Hi Andy, This gets to a common point of confusion with folks looking to extend Quantum: the difference between a plugin and a "driver" (unofficial term). Think of a plugin as a chunk of code that is responsible for accepting API calls like "create network", "create port", etc. Drivers on the other hand are device-specific code that know how to perform a particular task on a particular device (e.g., a brocade switch). You can definitely have a single plugin that communicates with different drivers to control different types of devices (the Cisco plugin has some examples of this, I believe). In my experience, it commonly breaks down this way: - the single plugin holds the logical network model and determines global state that applies across all switches (e.g., the VLAN being used to implement a particular network). - when nova schedules a VM workload in a particular location, the quantum plugin learns about the "binding" of that VM interface to a virtual/physical switch port. - the plugin invokes the driver specific to that virtual/physical switch along with global config state (e.g., a tenant VLAN) to perform the actual network configuration. The available plugins use a common code base for storing the logical data model and (if you choose) mapping it to a VLAN. It would likely be a pretty straightforward exercise for you to modify this code to work with a driver that talks Brocade switches instead of OVS or a Cisco switch. During the summit we talked about creating a plugin designed to simultaneously manage switches from multiple vendors by defining a standard driver interface in addition to the shared data model. I think the Cisco folks have taken some steps in that direction within their own plugin, so perhaps some of them can chime in. Dan Seems to me there needs to be a resource pool for switches, and when nova decides which compute node will host the VM, then 1 of the switches (maybe only 1) that is physically attached to that compute node is selected by quantum. Then the plugin for that switch is loaded (if it isn't already), and the plugin uses the switch(es) and port(s) that quantum tells it to use. Andy -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com<http://www.nicira.com> | www.openvswitch.org<http://www.openvswitch.org> Sr. Product Manager cell: 650-906-2650 ~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] API documentation ready for review
Hi, I read the API spec (again) and I have the same comment as last time. There are no normative definitions for any output from Quantum. IMO, a RelaxNG pattern is needed for every 'XML blob' that is defined by example. An application needs to know the XML or JSON structure to expect. It needs to know the list of enum strings to expect. How can I write a 'switch statement' in my application code for port-state when none of the enums are defined anywhere? If a formal spec is too hard, then how about specifying the data type for every field? (list all enums, and the rest are unconstrained strings?) If the enums are actually unconstrained strings, then programming to this API is going to be a 1-off for every plugin. That seems to be the plan so far. If so, the spec should say in bold letters "All values returned are implementation-dependent." Andy -Original Message- From: netstack-bounces+biermana=brocade@lists.launchpad.net [mailto:netstack-bounces+biermana=brocade@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Wednesday, September 21, 2011 5:05 PM To: netstack@lists.launchpad.net Subject: Re: [Netstack] API documentation ready for review And the documentation got updated again! This time we removed references to Keystone and reworked the Authentication section, trying to conveying the message that at the moment Quantum is not integrated with any authentication mechanism, but deployers are free to use their favourite mechanisms by appropriately configuring the Quantum pipeline. Also, Rajaram's contribute on API extensions has been integrated into the attached API guide. Salvatore > -Original Message- > From: Salvatore Orlando > Sent: 20 September 2011 00:56 > To: Salvatore Orlando; netstack@lists.launchpad.net > Subject: RE: API documentation ready for review > > Hello again, > > following your precious feedback, here's an updated version of the API > documentation. > Special thanks to Dan for his detailed review and for contributing the > section on Async behaviour. > > The branch on launchpad: lp:~salvatore-orlando/quantum/quantum-api-doc > has been updated as well. > > Salvatore > > From: netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net [netstack- > bounces+salvatore.orlando=eu.citrix@lists.launchpad.net] On Behalf > bounces+Of > Salvatore Orlando [salvatore.orla...@eu.citrix.com] > Sent: Thursday, September 15, 2011 6:09 PM > To: netstack@lists.launchpad.net > Subject: [Netstack] API documentation ready for review > > Hi Netstackers, > > The documentation for the Quantum API is now ready for review: > https://code.launchpad.net/~salvatore-orlando/quantum/quantum-api- > doc/+merge/75588 > Unfortunately there are no unit tests or compilers for documentation; > so I'm pretty sure there are several things to be fixed (page breaks for a > starter). > I would be therefore more than happy if you could have a look at it. > > In order to make things a bit easier for you, I'm attaching the PDF > version of the document, so you won't have to go through the docbook XML! > > Cheers, > Salvatore -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
Re: [Netstack] API documentation ready for review
Hi,
OK - I guess it is clear enough that the only allowed strings for port-state
are ACTIVE and DOWN, and hopefully the behavior for ACTIVE or DOWN
is roughly the same on all implementations.
It's more than a first step. It is very complete, except for the formal
schema..
Our application developers actually use them in their tools.
They will have to be generated from the text, if not included.
Since JSON doesn't have attributes (good!), a separate grammar for XML is
needed.
(Here is a start, hope it's right)
Port =
element port {
attribute id { text },
attribute state { "ACTIVE" | "DOWN" },
element attachment {
attribute id { test }
}?
}
Ports =
element ports { Port* }
Network =
element network {
attribute id { text },
attribute name { text },
Ports?
}
Andy
From: Dan Wendlandt [mailto:d...@nicira.com]
Sent: Thursday, September 22, 2011 10:36 AM
To: Andy Bierman
Cc: Salvatore Orlando; netstack@lists.launchpad.net
Subject: Re: [Netstack] API documentation ready for review
On Thu, Sep 22, 2011 at 10:00 AM, Andy Bierman
mailto:bierm...@brocade.com>> wrote:
Hi,
I read the API spec (again) and I have the same comment as last time.
There are no normative definitions for any output from Quantum.
IMO, a RelaxNG pattern is needed for every 'XML blob' that is defined
by example.
An application needs to know the XML or JSON structure to expect.
It needs to know the list of enum strings to expect.
How can I write a 'switch statement' in my application code
for port-state when none of the enums are defined anywhere?
If a formal spec is too hard, then how about specifying the data type
for every field? (list all enums, and the rest are unconstrained strings?)
If the enums are actually unconstrained strings, then programming to this API
is going to be a 1-off for every plugin. That seems to be the plan so far.
If so, the spec should say in bold letters
"All values returned are implementation-dependent."
Hi Andy,
Thanks for reviewing the doc. It is definitely still a work in progress, but I
think it is a great first step.
Can you be more specific about the enums that you are having trouble with? The
only enum that comes to my mind right away from the "core" API is port state,
and searching through the doc finds many mentions of the fact that "ACTIVE" and
"DOWN" are the two valid values for this field:
- Quantum API allows for controlling the administrative state of the port,
which can be either 'DOWN' or 'ACTIVE'.
- A port has an administrative state which is either 'DOWN' or 'ACTIVE'.
- Currently Quantum recognizes two port states: DOWN and ACTIVE.
It looks like the call to dump supported versions also has "CURRENT" and
"FUTURE", which probably could be defined explicitly, but that is a fairly
peripheral call.
Or am I misunderstanding what you are meaning by saying "enum"?
None of the values returned by a plugin should be plugin-specific unless part
of an extension that itself is plugin-specific. If there's something that
implies otherwise, we should try and clarify that in the text in the document.
I like the idea of having a more formal specification of the schema (I've used
JSON schema in the past, though it has its quirks). Ultimately, this is
probably an issue we should raise with the larger OpenStack API community, as
we would ideally all agree on common approach. I don't see any type of formal
spec even for "core" OpenStack projects like compute yet
(http://docs.openstack.org/trunk/openstack-compute/developer/openstack-compute-api-1.1/content/index.html),
but perhaps someone more knowledgable in that area can chime in. I
definitely think a blueprint to more formally define the spec would be welcomed.
Dan
Andy
-Original Message-
From:
netstack-bounces+biermana=brocade@lists.launchpad.net<mailto:brocade@lists.launchpad.net>
[mailto:netstack-bounces+biermana<mailto:netstack-bounces%2Bbiermana>=brocade@lists.launchpad.net<mailto:brocade@lists.launchpad.net>]
On Behalf Of Salvatore Orlando
Sent: Wednesday, September 21, 2011 5:05 PM
To: netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Subject: Re: [Netstack] API documentation ready for review
And the documentation got updated again!
This time we removed references to Keystone and reworked the Authentication
section, trying to conveying the message that at the moment Quantum is not
integrated with any authentication mechanism, but deployers are free to use
their favourite mechanisms by appropriately configuring the Quantum pipeline.
Also, Rajaram's contribute on API extensions has been integrated into the
attached API guide.
Salvatore
[Netstack] Latest nova and quantum versions that work together?
Hi,
I am not able to get lp:nova and lp:quantum to work together, even with the
FakePlugin.
(euca-run-instances fails. Using standard libvirt settings except
-libvirt_vif_type=bridge
instead of ethernet, but setting it to ethernet doesn't change the bug.)
It looks like a bug was just introduced into nova/network/quantum/manager.py.
The new get_all_networks() fn has an undefined symbol 'project_id'.
Before that (with last week's code) I hit a different bug in
nova/virt/libvirt/vif.py(LibvirtBridgeDriver._get_configurations).
result = {
'id': mac_id,
'bridge_name': network['bridge'],
'mac_address': mapping['mac'],
'ip_address': mapping['ips'][0]['ip'],
'dhcp_server': mapping['dhcp_server'],
'extra_params': extra_params,
}
There is no field network['bridge'].
This isn't the db/sqlalchemy/models(Network). This is part of a network,
mapping tuple
in network_info. Anyway, network['bridge'] is a uuid. (Hardwiring it to a name
like 'br100' or the bridge uuid causes
the VM start to fail because the bridge cannot be found.)
BTW, 'nova-manage config list' does not work either:
(nova): TRACE: File
"/usr/local/lib/python2.7/dist-packages/nova-2012.1-py2.7.egg/nova/flags.py",
line 138, in __getattr__
(nova): TRACE: val = getattr(self._values, name)
(nova): TRACE: AttributeError: Values instance has no attribute
'FlagsIntoString'
Are there versions of nova and quantum that work together yet?
Am I just configuring something wrong (just set NetworkManager to quantum)?
thanks,
Andy
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
