Thank you for your help and input.

This is a new installation, aiming at training myself to openstack. I follow as closely as possible the minimal deployment guides on https://docs.openstack.org/install-guide/openstack-services.html, for xena. I occasionally miss setting one parameter in the (long process) and sometime finding out what is missing, setting it right back is a tad of a challenge.

Everything worked fine until I tried to setup a second compute node. I could not deploy new VM on this second node if they are connected to the one provider network ("Binding failed for port xxx, please check neutron logs for more information."). I found out the reason was that both nodes had a different provider network name configured in /etc/neutron/plugins/ml2/linuxbridge_agent.ini\[DEFAULT]\physical_interface_mappings. Turns out correct name was on the newly installed node, so I deleted the provider network (and subnet, port and floating ips), fixed /etc/neutron/plugins/ml2/linuxbridge_agent.ini and /etc/neutron/plugins/ml2/ml2_conf.ini then I created the provider network again. Only then no network agent on the node I fixed could start, and the logs showed the content I gave in the first post.

Now, following your instructions, I attempt to enable logs for linuxbridge-agent. To do that I uncomment the line /etc/neutron/plugins/ml2/linuxbridge_agent.ini\[DEFAULT]\default_log_levels

default_log_levels = amqp=WARN,amqplib=WARN,boto=WARN,qpid=WARN,sqlalchemy=WARN,suds=INFO,oslo.messaging=INFO,oslo_messaging=INFO,iso8601=WARN,requests.packages.urllib3.connectionpool=WARN,urllib3.connectionpool=WARN,websocket=WARN,requests.packages.urllib3.util.retry=WARN,urllib3.util.retry=WARN,keystonemiddleware=WARN,routes.middleware=WARN,stevedore=WARN,taskflow=WARN,keystoneauth=WARN,oslo.cache=INFO,oslo_policy=INFO,dogpile.core.dogpile=INFO

in /etc/neutron/plugins/ml2/linuxbridge_agent.ini without touching the actual content as installed by the centos-stream-8 package (full line below), and I restart the linuxbridge-agent.

The log trace now mentions logs are enabled the the log trace look more like the reference you give. In fact, there is not trace of any error, and linuxbridge-agent seems to run normally:

[root@w3 ~]# openstack network agent list
+--------------------------------------+--------------------+---------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host          | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+---------------+-------------------+-------+-------+---------------------------+
| 330269b7-b73c-4207-abc7-21f1a2972b7b | Linux bridge agent | w6.int.lunarc | None              | :-)   | UP    | neutron-linuxbridge-agent |
| 83d16241-8a3a-42b0-beda-87246d945dc1 | L3 agent           | w3.int.lunarc | nova              | XXX   | UP    | neutron-l3-agent          |
| a52ab60f-d893-491d-a43e-823a0d482810 | Linux bridge agent | w3.int.lunarc | None              | :-)   | UP    | neutron-linuxbridge-agent |
| abd75644-d895-41ae-94fa-6c4351cbc4bf | Metadata agent     | w3.int.lunarc | None              | XXX   | UP    | neutron-metadata-agent    |
| c05c65bc-779e-4fe5-a19e-350c44900be4 | DHCP agent         | w3.int.lunarc | nova              | XXX   | UP    | neutron-dhcp-agent        |
+--------------------------------------+--------------------+---------------+-------------------+-------+-------+---------------------------+

It looks to me now that enabling the logs solved my problem and I can actually proceed. However, the info given in logs (systemd's journalctl) does not suggest the actual problem is logs must be enabled. Unless the actual issue is some hidden mishap that happens to disappear when logs are enabled.

I will now do the same for other network agents and hope for the best. I will post more here if one agent is still stuck.