<div>James,<br></div><div><br></div><div>After playing with this a little more, I think I have a way to handle this that is somewhat better than running as root directly:<br></div><div><br></div><div>1. Allow the ovsdb-server on the compute nodes to listen on 127.0.0.1:6640 (ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640:127.0.0.1)<br></div><div>2. Set the helper_command, ovsdb_connection, and the root_helper options in /etc/neutron/plugins/networking-ovn/networking-ovn-metadata-agent.ini as appropriate (example [1])<br></div><div><br></div><div>The process should start successfully as neutron.<br></div><div><br></div><div>I'm still having issues with agent liveness reporting, but it appears to be entirely superficial.  The agent works as expected.<br></div><div><br></div><div class="protonmail_signature_block"><div class="protonmail_signature_block-user"><div>r<br></div><div><br></div><div>Chris Apsey<br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><div>[1] <a href="https://github.com/GeorgiaCyber/kinetic/blob/networking-ovn/formulas/compute/files/networking_ovn_metadata_agent.ini">https://github.com/GeorgiaCyber/kinetic/blob/networking-ovn/formulas/compute/files/networking_ovn_metadata_agent.ini</a><br></div><div><br></div><div><br></div><div>‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br></div><div> On Wednesday, November 20, 2019 7:15 AM, James Denton <james.denton@rackspace.com> wrote:<br></div><div> <br></div><blockquote class="protonmail_quote" type="cite"><div><p>Hi Chris –<br></p><p> <br></p><p>I recall having the same issue when first implementing OVN into OpenStack-Ansible, and currently have the OVN metadata agent running as root[1]. I’m curious to see how others solved the issue as well. Thanks for bringing this up.<br></p><p> <br></p><p>[1] <a href="https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/vars/main.yml#L495-L496"> https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/vars/main.yml#L495-L496</a><br></p><p> <br></p><p> <br></p><div><p>James Denton<br></p><p>Network Engineer<br></p><p>Rackspace Private Cloud<br></p></div><p>james.denton@rackspace.com<br></p><p> <br></p><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p><b><span style="color:black"><span style="font-size:12pt">From: </span></span></b><span style="color:black"><span style="font-size:12pt">Chris Apsey <bitskrieg@bitskrieg.net><br> <b>Reply-To: </b>Chris Apsey <bitskrieg@bitskrieg.net><br> <b>Date: </b>Wednesday, November 20, 2019 at 12:00 AM<br> <b>To: </b>"openstack-discuss@lists.openstack.org" <openstack-discuss@lists.openstack.org><br> <b>Subject: </b>[neutron][ovn] networking-ovn-metadata-agent and neutron agent liveness</span></span></p></div><div><p> <br></p></div><div style="border:solid #9C6500 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt"><p style="line-height: 12pt; background-position: 0% 0%; background-repeat: repeat; background-attachment: scroll; background-image: none; background-size: auto; background-origin: padding-box; background-clip: border-box;"><span style="background-color:rgb(255, 235, 156)"><b><span style="color:rgb(156, 101, 0)"><span style="font-size:10pt">CAUTION:</span></span></b><span style="color:black"><span style="font-size:10pt"> This message originated externally, please use caution when clicking on links or
 opening attachments!</span></span></span><br></p></div><p> <br></p><div><div><p>All,<br></p></div><div><p> <br></p></div><div><p>Currently experimenting with networking-ovn (rdo/train packages on centos7) and I've managed to cobble together a functional deployment with two exceptions: metadata agents and agent liveness.<br></p></div><div><p> <br></p></div><div><p>Ref: the metadata issues, it appears that the local compute node ovsdb server listens on a unix socket at /var/run/openvswitch/db.sock as openvswitch:hugetlbfs 0750.  Since networking-ovn-metadata-agent runs as neutron, it's not able to
 interact with the local ovs database and gets stuck in a restart loop and complains about the inaccessible database socket.  If I edit the systemd unit file and let the agent run as root, it functions as expected.  This obviously isn't a real solution, but
 indicates to me a possible packaging bug?  Not sure what the correct mix of permissions is, or if the local database should be listening on tcp:localhost:6640 as well and that's how the metadata agent should connect.  The docs are sparse in this area, but
 I would imagine that something like the metadata-agent should 'just work' out of the box without having to change systemd unit files or mess with unix socket permissions.  Thoughts?<br></p></div><div><p> <br></p></div><div><p>Secondly, ```openstack network agent list``` shows that all agents (ovn-controller) are all dead, all the time.  However, if I display a single agent ```openstack network agent show $foo```, it shows as live.  I looked around and saw some
 discussions about getting networking-ovn to deal with this better, but as of now the agents are reported as dead consistently unless they are explicitly polled, at least on centos 7.  I haven't noticed any real impact, but the testing I'm doing is small scale.<br></p></div><div><p> <br></p></div><div><p>Other than those two issues, networking-ovn is great, and based on the discussions around possibly deprecating linuxbridge as an in-tree driver, it would make a great 'default' networking configuration option upstream, given the docs get
 cleaned up.<br></p></div><div><p> <br></p></div><div><p>Thanks in advance,<br></p></div><div><p> <br></p></div><div><div><div><p>r<br></p></div><div><p> <br></p></div><div><p>Chris Apsey<br></p></div></div><div><p> <br></p></div></div><div><p> <br></p></div></div></div></blockquote><div><br></div>