This group is locked. No changes can be made to the group while it is locked.
Re: openstack neutron ovsdb port creation
Baudinot Denis Gerold (badi) <badi@...>
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
Von: Sam Hague [shague@...]
Gesendet: Donnerstag, 9. Juli 2015 14:45
An: Baudinot Denis Gerold (badi)
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:
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.
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.