fixup the operator-sdk bundle #19
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #19 +/- ##
==========================================
+ Coverage 26.36% 26.74% +0.37%
==========================================
Files 75 75
Lines 5112 6146 +1034
==========================================
+ Hits 1348 1644 +296
- Misses 3600 4337 +737
- Partials 164 165 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
- Make sure the bundle is installed in the `bpfman` namespace rather than the openshift-bpfman namespace. - Update the SCC to be a bit more tight specifically making it run with runAsUser: type: MustRunAsNonRoot - Fixup some documentation Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
astoycos
force-pushed
the
operatorhub-updates
branch
3 times, most recently
from
bc7ea8e
to
aa17521
Compare
| // users can bind to in order to utilize bpfman in an unprivileged way. | ||
| func LoadRestrictedSecurityContext(path string) *osv1.SecurityContextConstraints { | ||
| // Load static SCC yaml from disk | ||
| file, err := os.Open(path) |
There was a problem hiding this comment.
why u decided to load static file instead of setting scc obj using APIs ?
There was a problem hiding this comment.
It's just how we've been doing it for all of the objects deployed by the bpfman-operator (i.e the bpfman-daemonset, csiDriver, and now SecurityContextConstraint) and IMO it usually ends up being a bit less code
There was a problem hiding this comment.
Additionally they all really didn't need to be configured at runtime at all (except for the bpfman ds) so I figured having them static on disk made sense
|
Hold until I can manually test on OCP, cluster bot is fighting me ATM |
astoycos
force-pushed
the
operatorhub-updates
branch
from
aa17521
to
c721b19
Compare
|
Tested on OCP 4.15 👍 |
astoycos
force-pushed
the
operatorhub-updates
branch
from
c721b19
to
8afc209
Compare
astoycos
force-pushed
the
operatorhub-updates
branch
from
8afc209
to
ba74b58
Compare
|
is there a need to write specific section in the readme for deploying on OCP cluster ? |
|
It's already there right? https://github.com/bpfman/bpfman-operator#deploy-to-openshift-cluster |
| get bpfman up and running quickly simply click 'install' to deploy the bpfman-operator | ||
| in the bpfman namespace via operator-hub.\n## Configuration\n\nThe `bpfman-config` | ||
| configmap is automatically created in the `bpfman` namespace and used to configure | ||
| the bpfman deployment.\n\nTo edit the config simply run\n\n```bash\nkubectl edit |
There was a problem hiding this comment.
Is the bundle more OCP specific? If so, should kubectl be replaced with oc?
There was a problem hiding this comment.
So technically the operatorhub is for everyone, and community operators prod is for OCP I think we can leave it as kubectl here and add a carry commit to https://github.com/redhat-openshift-ecosystem/community-operators-prod
As part of our default deployment in openshift we need to deploy a custom SCC which can be used by applications in order to receive access to their eBPF maps without running as root. update bundle based on changes. Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
astoycos
force-pushed
the
operatorhub-updates
branch
from
ba74b58
to
eb369fa
Compare
…ator Red Hat Konflux update ocp-bpfman-operator
Make sure the bundle is installed in the
bpfmannamespace rather than the openshift-bpfman namespace.Update the SCC to be a bit more tight specifically making it run with
runAsUser:
type: MustRunAsNonRoot
Fixup some documentation
Make the operator deploy our custom bpfman-restricted SCC if running in OCP