Meeting summary

[Renuka Manavalan]

NOTES:

1. HAMD @ host (PR #583) is *required* for the next set of mgmt. FW changes.
2. Klish talks to REST server using UNIX Socket domain within the mgmt. container.
3. Users ssh into host, run klish wrapper at host, which execs klish inside docker, with UID passed. Through hamd, the required user credentials are passed to the REST server.
4. REST Server serializes the incoming update requests, with a lock. The only concurrent update possibility is through GNMI server. The concurrent updates are ensured not to overstep though redis CAS lock.
5. OpenAPI api upgraded to version 3.0
6. Moving meeting from Bi-weekly to weekly to expedite.

 

 

Concerns:

1. Transformer calls into user provided overloaded methods, where translation to/fro is complex. But if there is a bug or an external induced cause, that holds up this method (say it is waiting for a lock to release or a blocked call or …), this can potentially hold up the entire transaction.

Even client-side timeout, would not help teardown this hanging/blocked transaction.

This seems to have potential to block subsequent updates, as the transaction is holding the lock.

 

@Anand Kumar Subramanian, would help clarify.

2. Broadcom is looking for the timeframe of June. The count of PRs is around 66 + HAMD-PR. Each PR is about 300+ lines in average to a total of ~24K lines of change. The HAMD is by itself is stated to be around 6000 lines of code. These PRs may be not tied tightly to D-Bus, but w/o it, some of the host level requests will not be feasible.

 

@Anand Kumar Subramanian’s PR info here Buzznic -- PRs review  (Web view)

 

Thank you,

Renuka

[Arun Barboza]

>>> 

1. Transformer calls into user provided overloaded methods, where translation to/fro is complex. But if there is a bug or an external induced cause, that holds up this method (say it is waiting for a lock to release or a blocked call or …), this can potentially hold up the entire transaction.

Even client-side timeout, would not help teardown this hanging/blocked transaction.

This seems to have potential to block subsequent updates, as the transaction is holding the lock.

>>>

FYI, it appears that the word "transaction" is overloaded here. The Transformer transactions appear to be different, and based on my understanding I do not know what locks are placed. The other use of "transaction" with regards to redis CAS is not a lock. So, one redis CAS transaction, if it fails, does not block another redis operation. I wanted to bring out this clarification so that appropriate calls are made based on correct information.

thanks

Arun

------------------------------------------------------------------------------------------------------------------------------------

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future

--------------------------------------------------------------------------------------------------------------------------------------

--
You received this message because you are subscribed to the Google Groups "sonic-mgmt-workgroup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonic-mgmt-workg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonic-mgmt-workgroup/BL0PR2101MB1089605E42101A2D246872769EA20%40BL0PR2101MB1089.namprd21.prod.outlook.com.

[Anand Kumar Subramanian]

Yes Arun, this is NOT the DB transaction but the REST transaction.