-
Notifications
You must be signed in to change notification settings - Fork 252
CNTRLPLANE-2241: kms: add helper for TechPreview V1 #2090
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
Conversation
|
/hold |
|
/lgtm |
| if container.Name != containerName { | ||
| continue | ||
| } | ||
| pod.Spec.Containers[i].VolumeMounts = append(container.VolumeMounts, |
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.
should we check if the mount doesn't already exist ? :)
otherwise we might add it multiple times.
also worth adding a test case for this ^
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.
Good point. This would be a problem if:
- This function is called multiple times per sync;
- Another routine adds a mount with the same name;
In both cases, I believe this function should fail rather than preventing the addition of the duplicate, and that's the currently behavior. Do you think it fail silently instead?
Alternatively, I could add a check with a different error, but I'm not sure it's worth it.
No strong opinions, though. I'm happy to change if you disagree.
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.
BTW, in pkg/operator/v1helpers/helpers.go we do the same thing
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.
Do you think it fail silently instead?
My idea was to simply check whether the volume/mount exists before adding it to the list.
I understand that the assumption is that this function will receive a pod that does not contain the volume/mounts.
If we don’t want to add these checks, would it make sense to at least document this assumption in the function’s docs?
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.
Makes sense, added a doc
| } | ||
|
|
||
| directoryOrCreate := corev1.HostPathDirectoryOrCreate | ||
| pod.Spec.Volumes = append(pod.Spec.Volumes, |
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.
should we check if the volume doesn't already exist ? :)
otherwise we might add it multiple times.
also worth adding a test case for this ^
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.
See my previous comment
| // FIXME: this is a temporary solution to get KMS TP v1 out. We should come up with a different approach afterwards. | ||
| func AddKMSPluginVolumeToPod(pod *corev1.Pod, containerName string, featureGateAccessor featuregates.FeatureGateAccess) error { | ||
| if !featureGateAccessor.AreInitialFeatureGatesObserved() { | ||
| return nil |
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 this is what we usually return when FG hasn't been observed, right ?
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.
Right, in that case it's not possible to make a decision
| ) | ||
|
|
||
| // AddKMSPluginVolumeToPod conditionally adds the KMS plugin volume mount to the kube-apiserver container. | ||
| // FIXME: this is a temporary solution to get KMS TP v1 out. We should come up with a different approach afterwards. |
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.
maybe we should also already Deprecate it :) ?
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.
That makes sense :)
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.
Changed it, but deprecated usually means "don't use this, use X instead", so it implies that an alternative exists
/hold cancel |
|
This looks good to me. But I'll defer the tag to @p0lyn0mial |
| ) | ||
|
|
||
| func TestAddKMSPluginVolume(t *testing.T) { | ||
| tests := []struct { |
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.
This is a personal preference.
I really like it when test definitions include inputs and expected outputs. It allows me to review test cases without looking at the logic.
If you feel the same way, we could slightly update the unit test to include actualPod and expectedPod (with the expected volumes).
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.
Ack; included actualPod and expectedPod
|
@bertinatto: all tests passed! 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. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ardaguclu, bertinatto, p0lyn0mial The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@bertinatto: This pull request references CNTRLPLANE-2241 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions 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 openshift-eng/jira-lifecycle-plugin repository. |
/assign @ardaguclu @benluddy @p0lyn0mial
Proof PR: openshift/cluster-kube-apiserver-operator#2015