Open Stack

Coming back to this after a break...

On my system (Ubuntu 12.04 Icehouse upgraded from havana) the agent
startup is clearly looking at the ml2_conf.ini and not the
openvswitch.ini:

# grep exec /etc/init/neutron-plugin-openvswitch-agent.conf
exec start-stop-daemon --start --chuid neutron --exec
/usr/bin/neutron-openvswitch-agent --
--config-file=/etc/neutron/neutron.conf
--config-file=/etc/neutron/plugins/ml2/ml2_conf.ini
--log-file=/var/log/neutron/openvswitch-agent.log

But I'm fairly sure that that's not my issue because I copied all the
bits from the ovs config into the ml2 while leaving the old one in
place so should be able to pull from either.

Looking at my situation with fresh eyes I notice that the tap device
is being tagged '4095' which according to
https://ask.openstack.org/en/question/13200/tap-devices-getting-tagged-to-4095/
means it's just dropped (exactly what I'm seeing) likely because the
compute agent isn't getting the network info it needs from the neutron
server.

Compute side I see:

2014-07-21 11:23:51.137 13152 DEBUG neutron.agent.linux.utils [-]
Running command: ['sudo', 'neutron-rootwrap',
'/etc/neutron/rootwrap.conf', 'ovs-vsctl', '--timeout=10', 'set',
'Port', 'tapadfbfa1c-d5', 'tag=4095'] create_process
/usr/lib/python2.7/dist-packages/neutron/agent/linux/utils.py:48
Command: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf',
'ovs-vsctl', '--timeout=10', 'set', 'Port', 'tapadfbfa1c-d5',
'tag=4095']
Stdout: '{"data":[["int-eth1-br",["set",[]]],["tapadfbfa1c-d5",4095],["patch-int",["set",[]]],["eth1",["set",[]]],["patch-tun",["set",[]]],["phy-eth1-br",["set",[]]],["br-int",["set",[]]],["br-tun",["set",[]]],["eth1-br",["set",[]]]],"headings":["name","tag"]}\n'
Stdout: '{"data":[["int-eth1-br",["set",[]]],["tapadfbfa1c-d5",4095],["patch-int",["set",[]]],["eth1",["set",[]]],["patch-tun",["set",[]]],["phy-eth1-br",["set",[]]],["br-int",["set",[]]],["br-tun",["set",[]]],["tap07fac3e5-72",["set",[]]],["eth1-br",["set",[]]]],"headings":["name","tag"]}\n'

Server side I'm seeing this warning:

2014-07-21 11:23:50.342 3244 WARNING
neutron.plugins.ml2.drivers.type_gre
[req-5658c379-0788-4b63-a5b4-54e63050
cea7 None] Gre endpoint with ip $COMPUTE_IP already exists
2014-07-21 11:23:51.066 3244 WARNING neutron.plugins.ml2.rpc
[req-5658c379-0788-4b63-a5b4-54e63050cea7 None] De
vice adfbfa1c-d5ee-450f-b434-05cc4639f74d requested by agent
ovsba3ef7afdc4e on network 0a1d0a27-cffa-4de3-92c5
-9d3fd3f2e74d not bound, vif_type: ovs

I wonder about the first server warning from the gre agent has me
worried a little since the network in question should be VLAN not GRE:

# neutron port-show adfbfa1c-d5ee-450f-b434-05cc4639f74d
+-----------------------+---------------------------------------------------------------------------------------+
| Field                 | Value
                                         |
+-----------------------+---------------------------------------------------------------------------------------+
| admin_state_up        | True
                                         |
| allowed_address_pairs |
                                         |
| binding:host_id       | pulsar-0
                                         |
| binding:profile       | {}
                                         |
| binding:vif_details   | {}
                                         |
| binding:vif_type      | ovs
                                         |
| binding:vnic_type     | normal
                                         |
| device_id             | 85d2f743-b48d-4271-85b3-97899d8c1ae9
                                         |
| device_owner          | compute:None
                                         |
| extra_dhcp_opts       |
                                         |
| fixed_ips             | {"subnet_id":
"76123b94-2ae9-40c4-a4c6-03ee98d081d9", "ip_address": "$vm_ip"} |
| id                    | adfbfa1c-d5ee-450f-b434-05cc4639f74d
                                         |
| mac_address           | fa:16:3e:f4:27:46
                                         |
| name                  |
                                         |
| network_id            | 0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d
                                         |
| security_groups       | 298a5c09-9df0-463b-b9bc-a647380bdee3
                                         |
|                       | e89ea050-10bc-42e7-99a8-18b97cec2446
                                         |
| status                | DOWN
                                         |
| tenant_id             | 17ea94ad74b64b9d92f4888336a598c7
                                         |
+-----------------------+---------------------------------------------------------------------------------------+

# neutron net-show 0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| id                        | 0a1d0a27-cffa-4de3-92c5-9d3fd3f2e74d |
| name                      | inet                                 |
| provider:network_type     | vlan                                 |
| provider:physical_network | trunk                                |
| provider:segmentation_id  | 2113                                 |
| router:external           | False                                |
| shared                    | True                                 |
| status                    | ACTIVE                               |
| subnets                   | 76123b94-2ae9-40c4-a4c6-03ee98d081d9 |
| tenant_id                 | 6f9adccbd03e4d2186756896957a14bf     |
+---------------------------+--------------------------------------+



On Thu, Jul 17, 2014 at 2:14 AM, Robert van Leeuwen
<Robert.vanLeeuwen at spilgames.com> wrote:
>>> After some wondering about why things did not work as expected I discovered that the daemon was not using the config file...
>>Is "the daemon" still referring to neutron-plugin-openvswitch-agent?
>
> Yes, the openvswitch daemon goes directly to the ovs_neutron_plugin.ini
>
>>> I also noticed I need to add the following to the ml2_conf to get it working with openvswitch (using vlans):
>>> [ovs]
>>> bridge_mappings = default:br-eth1
>>This should go in ovs_neutron_plugin.ini for
>>neutron-plugin-openvswitch-agent to read it. neutron-server does not
>>need this config as it is implementation details only required by the
>>mechanism agent.
>
> Ok, now I'm getting somewhere. Seems that I was mistaken in what used what.
> So the ml2 ini file is/should not used by the openvswitch agent but only by the server part?
>
>>I do agree that the relation between ml2_conf.ini and the mechanism
>>agent config file is not clear. I had to ask around, do some tests
>>and/or blinding trust the documentation. (which happens to work for me)
> Yep!
> It now makes some sense why stuff was not working :)
> I thought the ml2 plug also affected the openvswitch daemon but apparently that does not use this config at all?
> Somewhat weird as I understood this makes the agent more pluggable but it only affects the server part?
>
> Thx,
> Robert van Leeuwen
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators