<div dir="ltr"><div>Hello:</div><div><br></div><div>I think I'm repeating myself here but we have two approaches to solve this problem:</div><div>* The easiest one, at least for the L3 agent, is to report an INFO level log before and after the full sync. That could be parsed by any tool to detect that. You can propose a patch to the Neutron repository.<br></div><div>* <a href="https://bugs.launchpad.net/neutron/+bug/2011422">https://bugs.launchpad.net/neutron/+bug/2011422</a>: a more elaborated way to report the agent status. That could provide the start flag, the revived flag, the sync processing flag and many other ones that could be defined only for this specific agent.</div><div><br></div><div></div><div>Regards.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 20, 2023 at 4:33 PM Jan Horstmann <<a href="mailto:J.Horstmann@mittwald.de">J.Horstmann@mittwald.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2023-03-15 at 16:10 +0000, Felix Hüttner wrote:<br>
> Hi,<br>
> <br>
> > Subject: Re: [neutron] detecting l3-agent readiness<br>
> > <br>
> > Hi,<br>
> > <br>
> > Dnia poniedziałek, 13 marca 2023 16:35:43 CET Felix Hüttner pisze:<br>
> > > Hi Mohammed,<br>
> > > <br>
> > > > Subject: [neutron] detecting l3-agent readiness<br>
> > > > <br>
> > > > Hi folks,<br>
> > > > <br>
> > > > I'm working on improving the stability of rollouts when using Kubernetes as a control<br>
> > plane, specifically around the L3 agent, it seems that I have not found a clear way to<br>
> > detect in the code path where the L3 agent has finished it's initial sync..<br>
> > > > <br>
> > > <br>
> > > We build such a solution here: <a href="https://gitlab.com/yaook/images/neutron-l3-agent/-" rel="noreferrer" target="_blank">https://gitlab.com/yaook/images/neutron-l3-agent/-</a><br>
> > /blob/devel/files/startup_wait_for_ns.py<br>
> > > Basically we are checking against the neutron api what routers should be on the node and<br>
> > then validate that all keepalived processes are up and running.<br>
> > <br>
> > That would work only for HA routers. If You would also have routers which aren't "ha" this<br>
> > method may fail.<br>
> > <br>
> <br>
> Yep, since we only have HA routers that works fine for us. But I guess it should also work for non-ha routers without too much adoption (maybe just check for namespaces instead of keepalived).<br>
> <br>
<br>
Instead of counting processes I have been using the l3 agent's<br>
`configurations.routers` field to determine its readiness.<br>
>From my understanding comparing this number with the number of active<br>
routers hosted by the agent should be a good indicator of its sync<br>
status.<br>
Using two api calls for this is inherently racy, but could be a<br>
sufficient workaround for environments with a moderate number of<br>
router events.<br>
So a simple test snippet for the sync status of all agents could be:<br>
<br>
```<br>
import sys<br>
import openstack<br>
client = openstack.connection.Connection(<br>
   ...<br>
)<br>
l3_agent_synced = [<br>
    len([<br>
        router<br>
        for router in client.network.agent_hosted_routers(agent)<br>
            if router.is_admin_state_up<br>
    ]) <= client.network.get_agent(agent).configuration["routers"]<br>
    for agent in client.network.agents()<br>
        if agent.agent_type == "L3 agent"<br>
           and (agent.configuration["agent_mode"] == "dvr_snat"<br>
                or agent.configuration["agent_mode"] == "legacy")<br>
]<br>
if not all(l3_agent_synced):<br>
    sys.exit(1)<br>
```<br>
<br>
Please let me know if I am way off with this approach :)<br>
<br>
<br>
> > > <br>
> > > > Am I missing it somewhere or is the architecture built in a way that doesn't really<br>
> > answer that question?<br>
> > > > <br>
> > > <br>
> > > Adding a option in the neutron api would be a lot nicer. But i guess that also counts<br>
> > for l2 and dhcp agents.<br>
> > > <br>
> > > <br>
> > > > Thanks<br>
> > > > Mohammed<br>
> > > > <br>
> > > > <br>
> > > > --<br>
> > > > Mohammed Naser<br>
> > > > VEXXHOST, Inc.<br>
> > > <br>
> > > --<br>
> > > Felix Huettner<br>
> > > Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung<br>
> > durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger<br>
> > sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail.<br>
> > Hinweise zum Datenschutz finden Sie hier<<a href="https://www.datenschutz.schwarz" rel="noreferrer" target="_blank">https://www.datenschutz.schwarz</a>>.<br>
> > > <br>
> > <br>
> > <br>
> > --<br>
> > Slawek Kaplonski<br>
> > Principal Software Engineer<br>
> > Red Hat<br>
> <br>
> --<br>
> Felix Huettner<br>
> Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<<a href="https://www.datenschutz.schwarz" rel="noreferrer" target="_blank">https://www.datenschutz.schwarz</a>>.<br>
<br>
-- <br>
Jan Horstmann<br>
<br>
</blockquote></div>