Description of problem: clusterrole could not be patched/modified successfully Version-Release number of selected component (if applicable): # openshift version openshift v3.9.0-0.22.0 kubernetes v1.9.1+a0ce1bc657 etcd 3.2.8 How reproducible: always Steps to Reproduce: 1.edit clusterrole by cluster-admin user, such as delete some verb from clusterrole view 2.check the clusterrole view 3. Actual results: The clusterrole could not be patched successfully Expected results: The clusterrole could be patched successfully Additional info:
Admin, edit and view are owned by the cluster role aggregation controller. Any changes to them will be lost. You will need to modify the aggregate-to-* cluster roles instead. You can also check that editing other cluster roles still works as expected. See https://kubernetes.io/docs/admin/authorization/rbac/#aggregated-clusterroles for further details.
Then any changes for admin, edit and view clusterrole in OCP3.7, when cluster upgrade to 3.9, the changes will lost, do you think its make sense? And any potential impact?
We have one case totally the same scenario, make some changes for clusterrole view in 3.7, after cluster upgraded to 3.7, all the changes lost.
We need to investigate the impact on upgrades.
Chuan Yu, can you verify changes are preserved when you protect a role where you made changes over upgrades ? Cluster roles are *always* reconciled in 3.7 and forward at every server restart, so you have to protect the role if you make any changes. Please confirm that protecting the role and then upgrading works for you. [Note that protecting a role may cause other things to not work after upgrade if changes are necessary for new functionality]
> Then any changes for admin, edit and view clusterrole in OCP3.7, when cluster upgrade to 3.9, the changes will lost, do you think its make sense? And any potential impact? This is not the case. We copy the 3.7 values of those three cluster roles as the foundation for the three system:aggregate-to-* cluster roles in 3.9. Otherwise we break users on upgrade, which is not acceptable. > We have one case totally the same scenario, make some changes for clusterrole view in 3.7, after cluster upgraded to 3.7, all the changes lost. Did you make sure to add something to view? If you removed something, auto reconciliation will just add it back. > We need to investigate the impact on upgrades. There should be none (minus bugs in the migration code). > Cluster roles are *always* reconciled in 3.7 and forward at every server restart, so you have to protect the role if you make any changes. To be clear, you only have to protect removals. If you add stuff, reconciliation will not remove it (yet).
(In reply to Mo from comment #6) > > Then any changes for admin, edit and view clusterrole in OCP3.7, when cluster upgrade to 3.9, the changes will lost, do you think its make sense? And any potential impact? > > This is not the case. We copy the 3.7 values of those three cluster roles > as the foundation for the three system:aggregate-to-* cluster roles in 3.9. > Otherwise we break users on upgrade, which is not acceptable. > > We have one case totally the same scenario, make some changes for clusterrole view in 3.7, after cluster upgraded to 3.7, all the changes lost. > > Did you make sure to add something to view? If you removed something, auto > reconciliation will just add it back. yes, I have add some verb to apiGroups servicecatalog.k8s.io, but after upgrade to 3.9, the added verb all lost > > We need to investigate the impact on upgrades. > > There should be none (minus bugs in the migration code). > > > Cluster roles are *always* reconciled in 3.7 and forward at every server restart, so you have to protect the role if you make any changes. > > To be clear, you only have to protect removals. If you add stuff, > reconciliation will not remove it (yet). Yes, if I add stuff to protect clusterrole view to be reconciled, then the added verb will not lost, but the aggregate cluster feature will not take effective for clusterrole view.
https://github.com/openshift/origin/pull/18311 should fix the upgrade issue.
Commits pushed to master at https://github.com/openshift/origin https://github.com/openshift/origin/commit/e7022cdf3983e0893a0e263dc4699f9e482fcb21 Preserve aggregated cluster roles on upgrade This change adds admin, edit and view to the ClusterRolesToAggregate field in our bootstrap PolicyData. This guarantees that reconciliation will correctly preserve any changes made to these cluster roles before aggregation was enabled. Added a unit test to track aggregation based on the bootstrap PolicyData so changes are more obvious in the future. Bug 1537426 Signed-off-by: Monis Khan <mkhan> https://github.com/openshift/origin/commit/691975a816b52acf3f4cb26f95ede0204d2d5833 Merge pull request #18311 from enj/enj/i/migrate_cluster_role_aggregation_upgrade/1537426 Automatic merge from submit-queue (batch tested with PRs 16432, 18308, 18311). Preserve aggregated cluster roles on upgrade This change adds admin, edit and view to the ClusterRolesToAggregate field in our bootstrap PolicyData. This guarantees that reconciliation will correctly preserve any changes made to these cluster roles before aggregation was enabled. Added a unit test to track aggregation based on the bootstrap PolicyData so changes are more obvious in the future. [Bug 1537426](https://bugzilla.redhat.com/show_bug.cgi?id=1537426) Signed-off-by: Monis Khan <mkhan> /assign @deads2k @simo5 /kind bug
Verified. # openshift version openshift v3.9.0-0.48.0 kubernetes v1.9.1+a0ce1bc657 etcd 3.2.8
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0489