You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the Pending State:
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 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:
Cloud provider or hardware configuration: OCP on GCP
OS (e.g: cat /etc/os-release):
sh-5.1# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.4 (Plow)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="9.4"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Red Hat Enterprise Linux 9.4 (Plow)"
ANSI_COLOR="0;31"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:redhat:enterprise_linux:9::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9"
BUG_REPORT_URL="https://issues.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 9"
REDHAT_BUGZILLA_PRODUCT_VERSION=9.4
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.4"
Kernel (e.g. uname -a):
sh-5.1# uname -a
Linux ci-ln-jdyin4t-72292-tqgkv-master-0 5.14.0-427.52.1.el9_4.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 17 15:44:08 EST 2025 x86_64 x86_64 x86_64 GNU/Linux
Others:
The text was updated successfully, but these errors were encountered:
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>
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>
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: