✨ Add installer policy rule generators#1774
✨ Add installer policy rule generators#1774perdasilva wants to merge 5 commits intooperator-framework:mainfrom
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1774 +/- ##
==========================================
+ Coverage 68.93% 69.51% +0.58%
==========================================
Files 66 68 +2
Lines 5243 5343 +100
==========================================
+ Hits 3614 3714 +100
Misses 1397 1397
Partials 232 232
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
perdasilva
force-pushed
the
bundle-rbac
branch
2 times, most recently
from
38843e5 to
24b9633
Compare
perdasilva
changed the title
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
| return slices.Contains(clusterScopedResources, o.GetObjectKind().GroupVersionKind().Kind) | ||
| } | ||
|
|
||
| func isNamespaceScopedResource(o client.Object) bool { |
There was a problem hiding this comment.
since we expect the rendered manifests as input, I'm wondering if we could just check whether .metadata.namespace is set as the discriminant....
| ) | ||
|
|
||
| const ( | ||
| AnnotationRegistryV1GeneratedManifest = "io.operatorframework.olm.generated-manifest" |
There was a problem hiding this comment.
So it is a new annotation.
What happens when we use this new annotation?
Are we allowing the creation of RBAC rules for the Cluster Extension?
Is that? Can you please clarify when it is required and why? (for the POV of the Cluster Extension User)
There was a problem hiding this comment.
This is something we can talk about. This annotation exists only to inform the client of convert.Convert which of the resources where generated by it as opposed to coming directly from the bundle. Other than that, it does nothing. It's really just a signal to say "this resource was generated when rendering the bundle - it is not part of the bundle itself"
perdasilva
force-pushed
the
bundle-rbac
branch
2 times, most recently
from
0c5265b to
cdf1906
Compare
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
Signed-off-by: Per Goncalves da Silva <pegoncal@redhat.com>
| "ServiceMonitor", | ||
| "PodDisruptionBudget", | ||
| "VerticalPodAutoscaler", | ||
| "Deployment", |
There was a problem hiding this comment.
Hi @perdasilva 👋
Thanks for the PR! I just want to make sure I fully understand the implications of this change.
With this update, it looks like we're now generating the RBAC automatically, rather than asking authors to manually add it—am I reading that right? If so, are we aligned on this direction?
More specifically:
- 1 - Are we comfortable with the system creating permissions automatically?
- 2 - Do we currently auto-generate any permissions (e.g., for Secrets, ServiceAccounts, etc.)?
- If yes, then this seems like a natural extension of what we already do.
- If not, has this approach been discussed or agreed upon somewhere?
If the team is aligned and this was already considered, then I’m totally fine with it and happy to move forward with merging 🚀
Thanks again!
openshift-merge-robot
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions 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. |
|
closing as stale |
3 participants
Description
Adds functions to the rukpak/convert package to generate policy rules that can be used by the installer service account / user to manage a cluster extension.
Reviewer Checklist