decouple ib-sriov-cni with ib-kubernetes
zshi-redhat opened this issue · comments
ib-sriov-cni shall be able to run without ib-kubernetes be deployed for simple case such as InfiniBand network in default partition.
Currently ib-sriov-cni checks for existence of mellanox.infiniband.app annotation in CNI-Args and returns immediately if not annotated. This assumes ib-kubernetes be deployed when using ib-sriov-cni, which is not always the case.
correct we should have a flag to disable that check.
correct we should have a flag to disable that check.
Do we need a flag or we can just ignore the check if CNI-Args[annotation] doesn't exist?
If I understand correct, there maybe several re-try for ib-sriov-cni to get the CNI-Args because ib-kubernetes updates the CNI-Args periodically. Would it make sense to use webhook for GUID injection which happens before ib-sriov-cni is called?
So we got 3 cases:
- SM configuration: Required , GUID allocation : Required - Multi-tenancy
- SM configuration: Not Required, GUID allocation : Required (no PKeys) - No Multi-tenancy, GUID allocation required.
- SM configuration: Not Required , GUID allocation : Not required - No Multi-Tenancy, preconfigured GUIDs.
No Multi-Tenancy means all GUIDs are members on the default Pkey (SM configuration)
only for 1 we would need ib-kubernetes, having a webhook would allow do deploy a thinner component to satisfy 2 and prevent the retry.
downside is that we would need different components for different configurations
Personally, I think its a good idea.
Talking with @moshe010 it seems that for the time being we aim for 1. and 3.
so adding webhook, while a good idea, is not needed for now.
@adrianchiris @moshe010 is this what you have in mind: #38
It introduces a new flag called cniArgGUID (it's not a good name, we can revise later), and only get GUID from CNI_ARGS when the flag is set. This doesn't check infiniband Annotation explicitly, but assume it is configured when CNI_ARGS['guid'] exist.
As this #38 was merged. I am closing this issue.