[chassis]: Add chassis provisioning HLD - #2252
Conversation
|
/azp run |
|
No pipelines are associated with this pull request. |
Signed-off-by: Liam Kearney <liamkearney@microsoft.com>
71e974a to
e948e00
Compare
|
/azp run |
|
No pipelines are associated with this pull request. |
| ``` | ||
|
|
||
|
|
||
| ## New pmon daemon - sonic-provisiond |
There was a problem hiding this comment.
Is it necessary to have a separate daemon for this? Can this functionality not be folded into chassisd?
There was a problem hiding this comment.
Decided to go this way after a discussion with @arlakshm
Theres a few upsides of having it separate. If it's a separate daemon, disabling this feature becomes trivial. It also avoids creeping the scope for chassisd, and allows us to keep its role as "sync module state with statedb". It also simplifies keeping the state updated while conversion could potentially be running / allows us to block in provision_module() without having to block the chassisd thread (and avoid spinning out new threads in chassisd.)
So, yeah it could be folded in, but separating it out lets us avoid creeping the scope of chassisd & is more modular. If we are going through statedb anyway, there is no real need to strictly couple it with chassisd.
|
hi reviewers - PR for sonic-platform-common with API stubs / new states can be found here : sonic-net/sonic-platform-common#635 |
| # Module state when module is detected, is able to run SONiC, but is not yet running SONiC. | ||
| # Modules in this state will be attempted to be converted to SONiC via calls to module.provision_module() | ||
| # This state & following "Provision" states should not be used if provision_module() is not implemented. | ||
| MODULE_STATUS_PROVISION_READY = "ProvisionReady" |
There was a problem hiding this comment.
How is the vendor supposed to differentiate between MODULE_STATUS_PROVISION_PRESENT and MODULE_STATUS_PROVISION_READY ?
You cannot easily differentiate between a linecard that has been powered off and a linecard that you just inserted.
The mechanisms that I can think about would probably better live in the common infrastructure than the platform vendor API.
There was a problem hiding this comment.
They are very similar states, but PRESENT would indicate the state where the platform API does not support module provisioning / the module isn't ready for provisioning. Having a separate state allows the provisioning flow to be opt-in.
Module detection is fundamentally platform specific - what would be the common mechanism for detecting this? All vendors would have to agree if we want to move this logic to the SONiC layer - my personal opinion is SONiC shouldnt mandate the implementation details for this.
I dont see why there would be difficulty in differentiating between a linecard which is powered off vs just inserted. I would expect the platform to be able to manage/monitor the power states of the modules & "presence" to be decoupled from power state.
|
Thanks for your comments @Staphylo. Ive added some responses to your questions. Let me know if these answer your concerns, and I can update the HLD to be more clear. |
|
@kenneth-arista @patrickmacarthur @Staphylo |
6 participants
Add HLD for automatic module provisioning.
Introduces a new API and module operational states + pmon daemon to facilitate this within the sonic layer.
.md link with formatting: https://github.com/liamkearney-msft/SONiC/blob/liam/chassis-autoprovision/doc/chassis/module-provisioning/chassis-linecard-provisioning-hld.md