Comment 6 for bug 1888256

If I remember well, the router based metadata had been choosen because of High Availability considerations.
As I mentinoned, we started with Kilo in 2015.
Our design consists two dedicated network node, which runs the neutron-{ovs,l3,dhcp,metadata} agents.

And... I may not remember well with the next part (or it's just not true now, and may never was :) )

So, the DHCP high availability granted by running two independent DHCP agents (1-1 qdhcp on the network nodes/network with different IP addresses)

The router (1-1 router on network nodes/network) however only has one, but floating IP address with VRRP.

In DHCP based metadata, we (at least back in Kilo) not able to add both qDHCP instances with double static routes to the guests, therefor the HA was not granted. (or we missed something back then)

With the router based metadata, we added one static route with the "side" qrouter pair floating IP, so if one of our network node restarted/died/etc the another one got the floating IP by keepalived, and the metadata worked just fine.

Since our setup runs on production, this kind of change (qrouter to qdhcp metadata) is hard, beacuse this config change will have impact on all of our networks (but not impossible)

That's the reason, why I want to figure out our qrouter - radvd problem.

Maybe our unsuccessful tries with qdhcp metadata was based on a bug [*], which with Rocky just works fine, or we missed something with the configuration.

[*] https://bugzilla.redhat.com/show_bug.cgi?id=1256816

Back to the radvd problem:
I tried to understand the neutron code, and the radvd behaviour, and I may have a guess...
Neutron relevant code (in master, it's the same): https://github.com/openstack/neutron/blob/8c80267bb6699c86e10aade13c54b715e1eae1bf/neutron/agent/linux/ra.py

I've a few toughts:

1)
AdvSendAdvert on|off
A flag indicating whether or not the router sends periodic router advertisements and responds to router solicitations.

This option no longer has to be specified first, but it needs to be on to enable advertisement on this interface.

If I'm right, this option make radvd to "work" and because my ra_mode is none, therefor no prefix specification will generated in the radvd.conf, and the radvd possibly listen and advertise on all interfaces, which has IPv6 address.
Since this parameter hardcoded to Jinja template, it cannot be avoided.

2) _spawn_radvd(self, radvd_conf) function.
There are no condition, to check the ra_mode, so even if I set it to none, the process will be spawned.