[Ah/seq-diagram] Added Sequence Diagram For DpuNetworkCR with Disruptive Option#628
[Ah/seq-diagram] Added Sequence Diagram For DpuNetworkCR with Disruptive Option#628alkama-hasan wants to merge 1 commit intoopenshift:mainfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: alkama-hasan The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
needs-ok-to-test
|
Hi @alkama-hasan. Thanks for your PR. I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
alkama-hasan
changed the title
…end-to-end integration of DpuNetworkCR with the Disruptive option, covering DPU network creation, update, deletion, NF provisioning, and pod creation flows Signed-off-by: Alkama Hasan <alkamah@marvell.com>
alkama-hasan
force-pushed
the
disruptive-seq-diagram
branch
from
0b9068c to
0f88627
Compare
|
/ok-to-test |
openshift-ci
bot
added
ok-to-test
|
@alkama-hasan: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| @@ -0,0 +1,175 @@ | |||
| @startuml dpunetwork_cr_creation | |||
There was a problem hiding this comment.
@alkama-hasan
Impression 1: Why introduce a config map resource when we could use the DpuNetwork directly in the config daemon with the device plugin. We aren't going to be save any hits to the API with using ConfigMaps.
Also why does the controller need to consume the DPUNetwork?
There was a problem hiding this comment.
Controller would need the DPUNetwork to create the NAD, but besides that it should be ok.
| @@ -0,0 +1,175 @@ | |||
| @startuml dpunetwork_cr_creation | |||
|
|
|||
There was a problem hiding this comment.
Impression 2: Communication with the DPU's dpu daemon in my point of view should always be with gRPC regardless of 2 vs 1 cluster design.
The current design where the DPU dpu-daemon watching the config map assumes a 1 cluster design.
| @@ -0,0 +1,116 @@ | |||
| @startuml dpunetwork_cr_deletion | |||
There was a problem hiding this comment.
Similar to the create and the questions surrounding the config map usage.
| @@ -0,0 +1,165 @@ | |||
| @startuml pod_creation_regular | |||
There was a problem hiding this comment.
What is PodNetworkFunctionInfo? Is this a data structure inside the VSP? Who populates the data and where is it derived/created from?
There was a problem hiding this comment.
I think ideally we want to create a new resource towards the kubernetes API on what NF is created (like a status we can query). If the VSP crashes we lose everything and the state is not recoverable I think with this design. (because we don't know which RPM/SDP interfaces goes where).
This is my current understanding but I am not 100% sure.
2 participants
This commit adds comprehensive sequence diagrams that illustrate the end-to-end integration of DpuNetworkCR with the Disruptive option, covering DPU network creation, update, deletion, NF provisioning, and pod creation flows