This group is locked. No changes can be made to the group while it is locked.
Date
1 - 4 of 4
openstack neutron ovsdb port creation
|
Baudinot Denis Gerold (badi) <badi@...>
Hi,
I have read through ovsdb / openstack (helium), but I have issues identifiying the actual ovs port creation. Following from PortHandler.neutronPortCreated the only output I found is flow programming related. But what I want to see is where ovs ports are created through ovsdb. To be more specific I would like to see the part where the ovs ports and ovs interfaces are created by ovsdb, which are attached to tap devices to enable connectivity to VM instances in an openstack environment. I assume that the opendaylight.neutron bundle itself is only responsible for the northbound API to the neutron ml2 plugin and opendaylight.ovsdb does all the work regarding to ovs. Thank you |
|
|
|
Sam Hague
toggle quoted message
Show quoted text
----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>Baudinot, the ovsdb project will only add patch and tunnel ports as needed. The VM ports are added via the libvirt agent on the openstack compute nodes. The flow is like this: Network creation: 1. User creates a network via openstack 2. neutron agents add ports to bridges for routers and dhcp namespaces - these are the tap ports you mention above 3. neutron and ovsdb port updates go to odl 4. neutron events passed to odl ovsdb project - not much happens here 5. ovsdb port events go directly to the odl ovsdb 6. odl ovsdb will relate the neutron events to the ovsdb events and build tunnels and push flows as needed. VM Creation: 1. User creates VM's via openstack 2. nova calls libvirt to create VM 3. libvirt calls will allocate VM ports and add them to the br-int - these are the tap ports you mention above 4. Same as 3-6 above. yes, odl.neutron receives the incoming neutron rest APIs. And then effectively passes them through to odl.ovsdb to do the work.
|
|
|
|
Baudinot Denis Gerold (badi) <badi@...>
Hi again
I'am trying to understand the relation you mentioned here: 6. odl ovsdb will relate the neutron events to the ovsdb events and build tunnels and push flows as needed.I can't figure this out in the case of a neutron port creation. The neutron port creation gets passed to the PortHandler. But the NetworkingProvider which is responsible for pushing l2 forwarding flows onto the bridge is neither notified by a southbound event nor the mentioned neutron event. The southbound event ADD for port creation is empty. Only UPDATE seems to pass on the creation to the NetworkingProvider. Where can I see the relation between the southbound port creation and neutron port creation? What confuses me on the side is the fact that the southbound events require to retrieve a NeutronNetwork from the neutron cache. What happens if the neutron event happens after the southbound event? Thank you *very* much again Denis ________________________________________ Von: Sam Hague [shague@...] Gesendet: Donnerstag, 9. Juli 2015 14:45 An: Baudinot Denis Gerold (badi) Cc: ovsdb-dev@... Betreff: Re: [ovsdb-dev] openstack neutron ovsdb port creation ----- Original Message ----- From: "Baudinot Denis Gerold (badi)" <badi@...>Baudinot, the ovsdb project will only add patch and tunnel ports as needed. The VM ports are added via the libvirt agent on the openstack compute nodes. The flow is like this: Network creation: 1. User creates a network via openstack 2. neutron agents add ports to bridges for routers and dhcp namespaces - these are the tap ports you mention above 3. neutron and ovsdb port updates go to odl 4. neutron events passed to odl ovsdb project - not much happens here 5. ovsdb port events go directly to the odl ovsdb 6. odl ovsdb will relate the neutron events to the ovsdb events and build tunnels and push flows as needed. VM Creation: 1. User creates VM's via openstack 2. nova calls libvirt to create VM 3. libvirt calls will allocate VM ports and add them to the br-int - these are the tap ports you mention above 4. Same as 3-6 above. yes, odl.neutron receives the incoming neutron rest APIs. And then effectively passes them through to odl.ovsdb to do the work.
|
|
|
|
Sam Hague
toggle quoted message
Show quoted text
----- Original Message -----
From: "Baudinot Denis Gerold (badi)" <badi@...>The SouthboundHandler is where the ovs port updates come in. Both the add and update are mapped to a processPortUpdate() since we want to do the same thing for both events. As you saw int he code the PortHandler really doesn't do much. That code is really just there so that the neutron northbound will not reply negatively to neutron rest calls - something is required int he backend to satisfy the request. So when the ovs port is updated we can then go to program the flows in the handleinterfaceUpdate() method. I don't recall everything that comes in for the port add and update but we can't do anything until the external_ids column is filled with the neutron port iface-id so that we know how to program the flows for the requested network. That is the link between the neutron port and the ovs port. It always works out that eventually the neutron port stuff comes in followed by a ovs port update. Sometimes there are ovs port add/updates before the neutron port comes in, but in all cases there is a subsequent ovs port update. So eventually you get an ovs update and the neutron cache is there for use.
|
|
|