-
Notifications
You must be signed in to change notification settings - Fork 11
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
OPCT-6 - fix/rbac: manage custom ServiceAccount and roles #34
OPCT-6 - fix/rbac: manage custom ServiceAccount and roles #34
Conversation
95fd8cd
to
469f2cb
Compare
Converted to draft as the results with this RBAC seems not to be good: https://issues.redhat.com/browse/SPLAT-874?focusedCommentId=21301414&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-21301414 |
/hold |
469f2cb
to
8ff982f
Compare
/unhold This lgtm so far but I'll run a quick test before approving. @mtulio can you remove draft state from this PR? |
543dd23
to
a0b0488
Compare
/lgtm I have a test running in AWS right now and if it looks good, I'll approve. |
034ee81
to
ff191d9
Compare
ff191d9
to
aed8313
Compare
@bostrt I ran tests onto 4.11 (regular mode) and got good results, similar failures ratio as v0.2.1+ (less than 1%). I am ok to a final review, then backport to v0.2.
/unhold |
/unhold |
@bostrt I am thinking that we don't need to backport this PR to v0.2 for the following reasons:
Let me know your thoughts. |
@mtulio I was originally thinking we could separate the RBAC work from the upgrade work in 0.3 but if you want to work on stabilizing 0.2 that works for me. |
@bostrt yes, we are working to stabilize v0.3/upgrades, but I was thinking in scenarios if we need it on the older releases. But nothing came to my mind. I am ok to merge here and not back port to v0.2. |
This works for me too. If anything comes up, we can always backport. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bostrt 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 |
https://issues.redhat.com/browse/SPLAT-651 Support upgrade conformance. - Introduces new flags to control whether the execution needs to run the upgrade cluster or not: - `--mode=upgrade` - `--upgrade-to-image=<release_digest>` (`$(oc adm release info 4.Y+1.Z -o jsonpath={.image}`) - Create config map with plugin variables (the sonobuoy native feature wipes all existing from `podSpec` which is undesired) - add a new plugin instance of openshift-tests to run upgrades: `05-openshift-cluster-upgrade` Blocked by: - [x] #31 - [x] #34 Blocked by Plugin release: - [x] redhat-openshift-ecosystem/provider-certification-plugins#24 Checklist: - [x] CLI changes to run in upgrade mode - [x] CLI changes to get the release image digest - [x] Plugin implementation: redhat-openshift-ecosystem/provider-certification-plugins#24 - [x] Validate y-stream upgrades - [x] Fix RBAC #34 for Cluster upgrade - [x] Fix SecurityContextMode for Sonobuoy aggregator stuck on 4.10->4.11 #39 - [x] MachineConfigPool validation: 'opct' object is validated if present when running `mode=upgrade` on the runtime (plugin execution). Failures will be raised by the plugin when the MCP is not present (the User Docs should keep it very explicit): Tests described here: redhat-openshift-ecosystem/provider-certification-plugins#24 (comment) - [x] User Documentation Tests checklist: - [x] upgrade 4.12-> 4.13
https://issues.redhat.com/browse/OPCT-6
This PR creates custom permissions to be used on Sonobuoy's service accounts.
The default sonobuoy's permissions are crashing the cluster upgrade feature (implemented on #33), described on OPCT-6. The goal is to avoid using system groups to not fall into pod admissions security admissions introduced on kube 1.24 (4.11).
The groups
system:authenticated
andsystem:serviceaccounts
previously used were crashing the upgrade. Ref KCS 5875621Tests checklist: