Skip to content

Commit 5aad3fc

Browse files
abdosidivyachandralekha
authored andcommitted
Fix State Db LAG_MEMBER_TABLE removal not happening. (sonic-net#3347)
What I did: Original issue and and PR: sonic-net#3333 Why I did: Fix the failure in test_po_update.py as seen in this PR checker: sonic-net/sonic-buildimage#20610 Previous fix blocked State Db LAG_MEMBER_TABLE deletion which is not correct as this table is created by tlm_teamd (owner). Intention was to prevent deletion of State Db LAG_TABLE owner of which is teamsyncd.
1 parent e2bbebb commit 5aad3fc

File tree

1 file changed

+9
-7
lines changed

1 file changed

+9
-7
lines changed

tlm_teamd/values_store.cpp

+9-7
Original file line numberDiff line numberDiff line change
@@ -281,6 +281,14 @@ void ValuesStore::remove_keys_db(const std::vector<std::string> & keys)
281281
const auto & p = split_key(key);
282282
const auto & table_name = p.first;
283283
const auto & table_key = p.second;
284+
// Do not delete te key from State Db for table LAB_TABLE. LAB_TABLE entry is created/deleted
285+
// from teamsyncd on detecting netlink of teamd dev as up/down. For some reason
286+
// if we do not get state dump from teamdctl it might be transient issue. If it is
287+
// persistent issue then teamsyncd might be able to catch it and delete state db entry
288+
// or we can keep entry in it's current state as best effort. Similar to try_add_lag which is best effort
289+
// to connect to teamdctl and if it fails we do not delete State Db entry.
290+
if (table_name == "LAG_TABLE")
291+
continue;
284292
swss::Table table(m_db, table_name);
285293
table.del(table_key);
286294
}
@@ -366,13 +374,7 @@ void ValuesStore::update(const std::vector<StringPair> & dumps)
366374
{
367375
const auto & storage = from_json(dumps);
368376
const auto & old_keys = get_old_keys(storage);
369-
// Do not delete te key from State Db. State DB LAB_TABLE entry is created/deleted
370-
// from teamsyncd on detecting netlink of teamd dev as up/down. For some reason
371-
// if we do not get state dump from teamdctl it might be transient issue. If it is
372-
// persistent issue then teamsyncd might be able to catch it and delete state db entry
373-
// or we can keep entry in it's current state as best effort. Similar to try_add_lag which is best effort
374-
// to connect to teamdctl and if it fails we do not delete State Db entry.
375-
//remove_keys_db(old_keys);
377+
remove_keys_db(old_keys);
376378
remove_keys_storage(old_keys);
377379
const auto & keys_to_refresh = update_storage(storage);
378380
update_db(storage, keys_to_refresh);

0 commit comments

Comments
 (0)