can't load security-profiles-operator as dependancy of another operator #2746
Conversation
|
Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it. 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. |
k8s-ci-robot
added
do-not-merge/invalid-commit-message
|
Welcome @Billy99! |
k8s-ci-robot
added
the
needs-ok-to-test
|
Hi @Billy99. Thanks for your PR. I'm waiting for a kubernetes-sigs 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. 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. |
k8s-ci-robot
added
the
size/M
|
/ok-to-test |
k8s-ci-robot
added
ok-to-test
k8s-ci-robot
added
lgtm
|
/lgtm cancel CI is not happy: |
k8s-ci-robot
removed
the
lgtm
Billy99
force-pushed
the
billy99-getds
branch
2 times, most recently
from
f491457 to
514e07b
Compare
When loaded through OperatorHub as a dependency of another operator, security-profiles-operator is loaded in the namespace of the other operator. When this happens, any created SelinuxProfile stays in the Pending State. It appears that the function getDS() is searching for the DaemonSet with a label of "spod". However, the r.client.List() call is returning all DaemonSets in the Namespace and bailing because it found more than one. This commit changes the logic to call Get() instead of GetList(). Resolves: kubernetes-sigs#2699 Signed-off-by: Billy McFall <[email protected]>
Billy99
force-pushed
the
billy99-getds
branch
from
514e07b to
1a64f22
Compare
|
Keywords which can automatically close issues and at(@) or hashtag(#) mentions are not allowed in commit messages. The list of commits with invalid commit messages:
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. |
Recently SelinuxProfile was moved from Namespace scoped to cluster scoped. Some of the code was still using the Namespace as part of the generation of the "Usage" string. The Namespace was blank, so the usage string just ended in an "_", something like "policyName_.process". However, workloadannotator was using the application pods namespace and the code strip the "_namspace.process" off the usage string to get the actual profile name was failing. So just removed all the logic was append "_namespace" to the profile name in the usage. Resolves: kubernetes-sigs#2745 Signed-off-by: Billy McFall <[email protected]>
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Billy99, ccojocar, saschagrunert The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2746 +/- ##
===========================================
- Coverage 45.50% 23.32% -22.19%
===========================================
Files 79 116 +37
Lines 7782 19707 +11925
===========================================
+ Hits 3541 4596 +1055
- Misses 4099 14893 +10794
- Partials 142 218 +76 |
What type of PR is this?
/kind bug
What this PR does / why we need it:
For #2699
When loaded through OperatorHub as a dependency of another operator, security-profiles-operator is loaded in the namespace of the other operator. When this happens, any created SelinuxProfile stays in the Pending State.
It appears that the function getDS() is searching for the DaemonSet with a label of "spod". However, the r.client.List() call is returning all DaemonSets in the Namespace and bailing because it found more than one.
This commit changes the logic to call Get() instead of GetList().
While trying to verify the above, ran into issues with the move of SelinuxProfile from namespace scoped to cluster scoped (#2745). Recently SelinuxProfile was moved from Namespace scoped to cluster scoped. Some of the code was still using the Namespace as part of the generation of the "Usage" string. The Namespace was blank, so the usage string just ended in an "_", something like "policyName_.process". However, workloadannotator was using the application pods namespace and the code to strip the "_namspace.process" off the usage string to get the actual profile name was failing. So just removed all the logic was appending "_namespace" to the profile name in the Usage since namespace is no longer used.
Which issue(s) this PR fixes:
Fixes #2699
Fixes #2745
Does this PR have test?
No, but the linked issues describe how to reproduce.
Special notes for your reviewer:
Does this PR introduce a user-facing change?
The Usage should no longer have an "_" after the profile name.