-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use ConfigMap to store supported NIC model list #145
Conversation
api/v1/helper.go
Outdated
sort.Slice(NicIdMap, func(i, j int) bool { | ||
ip, _ := strconv.ParseInt(NicIdMap[i], 0, 32) | ||
jp, _ := strconv.ParseInt(NicIdMap[j], 0, 32) | ||
return ip < jp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ip & jp always resolve to 0
https://play.golang.org/p/rqy0xpHulpG
return err | ||
} | ||
for _, v := range cm.Data { | ||
NicIdMap = append(NicIdMap, v) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we make the existing NicIdMap blank? Its currently populated on Ln 40.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, forget to remove the old initialization code.
How will configmap be updated when new IDs are added in configmap during upgrade? |
deploy/configmap.yaml
Outdated
metadata: | ||
name: supported-nic-ids | ||
data: | ||
I40e_XXV710: "8086 158a 154c" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we define a consistent name format for the data keys?
For example:
<vendor_driver_model_name>
Intel_ice_E810_Columbiaville
Nvidia_mlx5_MT42882_ConnectX-5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can do that. But keep in mind, the NIC name here is not used in the code logic, it is just for readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pliurh are you going to update the keys here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
During an upgrade, the ConfigMap shall be updated first, then the pod images. So that we can guarantee pods start with the right ConfigMap. |
Who updates the configMap? and How? |
Users shall update the ConfigMap for the upstream version. For the downstream version, the OLM can update the ConfigMap. operator-framework/operator-lifecycle-manager#1434 |
Use a ConfigMap 'supported-nic-ids' to store the NIC model list to replace the current hardcoded list. Deprecate the ConfigMap 'unsupported-nic-ids'. Also deprecate the machanism which allow users can change the content of ConfigMap on the fly. Now users have to restart the webhook and config daemon pods after changing the ConfigMap.
/lgtm |
close #86 |
@adrianchiris PTAL |
/cc @akaris-redhat |
Use a ConfigMap 'supported-nic-ids' to store the NIC model list
to replace the current hardcoded list. Deprecate the ConfigMap
'unsupported-nic-ids'.
Also deprecate the machanism which allow users can change the
content of ConfigMap on the fly. Now users have to restart the
webhook and config daemon pods after changing the ConfigMap.