Skip to content

Conversation

@bertinatto
Copy link
Member

@bertinatto bertinatto commented Jan 26, 2026

@openshift-ci openshift-ci bot requested review from dgrisonnet and tkashem January 26, 2026 19:45
@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 26, 2026
@bertinatto
Copy link
Member Author

/hold
For openshift/api#2669

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 26, 2026
@ardaguclu
Copy link
Member

/lgtm
This looks good to me. I also opened #2091 for the new FG.

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 27, 2026
if container.Name != containerName {
continue
}
pod.Spec.Containers[i].VolumeMounts = append(container.VolumeMounts,
Copy link
Contributor

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 ^

Copy link
Member Author

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:

  1. This function is called multiple times per sync;
  2. 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.

Copy link
Member Author

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

Copy link
Contributor

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?

Copy link
Member Author

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,
Copy link
Contributor

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 ^

Copy link
Member Author

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
Copy link
Contributor

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 ?

Copy link
Member Author

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.
Copy link
Contributor

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 :) ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense :)

Copy link
Member Author

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

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Jan 27, 2026
@bertinatto
Copy link
Member Author

From https://prow.ci.openshift.org/view/gs/test-platform-results/logs/openshift-cluster-kube-apiserver-operator-2015-nightly-4.22-e2e-vsphere-ovn-techpreview/2016149344322850816:

$ omc get featuregate cluster -o jsonpath='{.status.featureGates[].enabled[?(@.name=="KMSEncryption")]}'
{"name":"KMSEncryption"}

$ omc -n openshift-kube-apiserver get pod/kube-apiserver-ci-op-5npgdx95-b7629-bbrjx-master-0 -o json | jq .spec.containers[0].volumeMounts[5]
{
  "mountPath": "/var/run/kmsplugin",
  "name": "kms-plugin-socket"
}

$ omc -n openshift-kube-apiserver get pod/kube-apiserver-ci-op-5npgdx95-b7629-bbrjx-master-0 -o json | jq .spec.volumes[5]
{
  "hostPath": {
    "path": "/var/run/kmsplugin",
    "type": "DirectoryOrCreate"
  },
  "name": "kms-plugin-socket"
}

/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jan 27, 2026
@ardaguclu
Copy link
Member

This looks good to me. But I'll defer the tag to @p0lyn0mial

)

func TestAddKMSPluginVolume(t *testing.T) {
tests := []struct {
Copy link
Contributor

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).

Copy link
Member Author

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

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 28, 2026

@bertinatto: all tests passed!

Full PR test history. Your PR dashboard.

Details

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.

@p0lyn0mial
Copy link
Contributor

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 29, 2026
@p0lyn0mial p0lyn0mial changed the title kms: add helper for TechPreview V1 CNTRLPLANE-2241: kms: add helper for TechPreview V1 Jan 29, 2026
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 29, 2026

[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

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jan 29, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jan 29, 2026

@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.

Details

In response to this:

/assign @ardaguclu @benluddy @p0lyn0mial

Proof PR: openshift/cluster-kube-apiserver-operator#2015

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.

@openshift-merge-bot openshift-merge-bot bot merged commit 9382c11 into openshift:master Jan 29, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants