Conversation
Signed-off-by: Yue Gao <yuega2@cisco.com>
|
/azp run |
|
|
||
| self.update_dash_ha_set_table(&vdpus, incoming, outgoing)?; | ||
|
|
||
| if !first_time { |
There was a problem hiding this comment.
Can pinned state be part of initial config?
There was a problem hiding this comment.
It can be. first_time check is set when the actor first receives ha_set_config. At the first time, it will register with VDpu actors. Only after the actor receives VDpu update, which won't happen when it's the first_time, and DashHaGlobalConfig, it is ready to create vnet route. In the corresponding VDpu update and DashHaGlobalConfig, there is call of self.update_vnet_route_tunnel_table. If the pinned state in the initial ha_set_config, it will be set by those calls. Here is only to handle ha_set_config update.
|
/azp run |
zjswhhh
left a comment
zjswhhh
left a comment
There was a problem hiding this comment.
When pinned_state is updated, will the list of monitor IPs and endpoint IPs be written along with it again?
Yes, it is a complete rewrite with all the attributes. |
|
hi @zjswhhh , what will happen if this change goes in before VnetOrch supports pinned_state? will it be ignored? |
Good catch, I think orchagent will throw exception because the field is not expected. :( |
|
ok. Let's hope your vnetorch change going in quickly. In the meantime, we have to exclude the PR when building a new image. |
Please help review: sonic-net/sonic-swss#4150 |
|
Cherry-pick PR to msft-202506: Azure/sonic-dash-ha.msft#22 |
This reverts commit 17e2e0b.
5 participants
What I did
Implement BFD pinned state in ha_set_config_table.
Why I did it
Missing feature
How I verified it
Verified with unit test (will verify in hardware when VnetOrch supports pinned_state)
Details if related