-
Notifications
You must be signed in to change notification settings - Fork 116
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
can't load security-profiles-operator as dependancy of another operator #2699
Labels
kind/bug
Categorizes issue or PR as related to a bug.
Comments
Billy99
added a commit
to Billy99/bpfman-operator
that referenced
this issue
Feb 11, 2025
After deploying the selinux profile, the status on the Selinux Profile is “Pending”. security-profiles-operator is currently deployed in OpenShift by making it a dependency of bpfman-operator. As a result, the security-profiles-operator is deployed in the bpfman namespace. security-profiles-operator encounters issues with this because there are other daemonsets in the namespace. Short term, remove the dependency. security-profiles-operator is still required, it just won't be auto-installed. Related: bpfman#331 Related: kubernetes-sigs/security-profiles-operator#2699 Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com>
This was referenced Feb 11, 2025
Billy99
added a commit
to Billy99/bpfman-operator
that referenced
this issue
Feb 13, 2025
After deploying the selinux profile, the status on the Selinux Profile is “Pending”. security-profiles-operator is currently deployed in OpenShift by making it a dependency of bpfman-operator. As a result, the security-profiles-operator is deployed in the bpfman namespace. security-profiles-operator encounters issues with this because there are other daemonsets in the namespace. Short term, remove the dependency. security-profiles-operator is still required, it just won't be auto-installed. Related: bpfman#331 Related: kubernetes-sigs/security-profiles-operator#2699 Signed-off-by: Billy McFall <22157057+Billy99@users.noreply.github.com>
Billy99
added a commit
to Billy99/security-profiles-operator
that referenced
this issue
Feb 28, 2025
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 <22157057+Billy99@users.noreply.github.com>
Billy99
added a commit
to Billy99/security-profiles-operator
that referenced
this issue
Feb 28, 2025
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 <22157057+Billy99@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With the security-profiles-operator.v0.8.6
What happened:
bpfman-operator has a dependency on security-profiles-operator. When loaded as a dependency through OperatorHub, security-profiles-operator is loaded in the bpfman namespace. When this happens, any created
SelinuxProfile
stays in thePending
State:SelinuxProfile in Pending State
It appears that the function
getDS()
is searching for the DaemonSet with a label of "spod".security-profiles-operator/internal/pkg/manager/nodestatus/nodestatus.go
Line 250 in 4dd6f55
However, the
r.client.List()
call is returning all DaemonSets in the Namespace. I'm not sure why the LabelSelector is being ignored, but if it wasn't, the spod DaemonSet does not have any labels so the LabelSelector wouldn't have found anything anyway.Because the
getDS()
call fails to find the spod DaemonSet, the reconciler bails and fails reconcile fully.security-profiles-operator Logs
spod DaemonSet
What you expected to happen:
security-profiles-operator to load properly and the SelinuxPolicy to go to the
Installed
state.How to reproduce it (as minimally and precisely as possible):
Load security-profiles-operator in a namespace that has another DaemonSet. bpdman-operator has a dependency to pull in the security-profiles-operator (https://github.com/bpfman/bpfman-operator/blob/main/bundle/metadata/dependencies.yaml) which caused them to load in the same namespace, but loading any DaemonSet in the same namespace as security-profiles-operator then creating a SelinuxProfile should reproduce the issue.
Anything else we need to know?:
If I manually load security-profiles-operator from OperatorHub, it gets created in it's own namespace and when the SelinuxProfile is created, it goes ot the
Installed
state as expected.Environment:
cat /etc/os-release
):uname -a
):The text was updated successfully, but these errors were encountered: