Description of problem: Non HA cluster upgrade to 3.9, lack a step to restart master service to let the aggregate clusterrole take effective Version-Release number of the following components: ansible-2.4.2.0-2.el7.noarch openshift-ansible-3.9.0-0.24.0.git.0.735690f.el7.noarch How reproducible: always Steps to Reproduce: 1.setup OCP3.7 cluster, 1 master + 1 node, v3.7.26 2.upgrade cluster to OCP3.9, v3.9.0-0.24.0 3.oc get clusterrole | grep aggregate Actual results: no aggregate-* clusterrole found Expected results: There should have some aggregate clusterrole output, # oc get clusterrole | grep aggregate system:aggregate-to-admin system:aggregate-to-edit system:aggregate-to-view system:openshift:aggregate-to-admin system:openshift:aggregate-to-edit system:openshift:aggregate-to-view Additional info: When manually reatart api and controllers service, the aggregate clusterrole take effective.
This may be related to https://bugzilla.redhat.com/show_bug.cgi?id=1537426 which should be fixed by https://github.com/openshift/origin/pull/18311
Verified failed. When non-ha OCP cluster upgrade to OCP 3.9.0-0.36.0 from v3.7.27, still need restart master service to let the aggregate clusterrole take effective.
> 2.upgrade cluster to OCP3.9, v3.9.0-0.24.0 Does this step restart the master? i.e. a master reboot is _always_ required after an upgrade.
(In reply to Mo from comment #5) > > 2.upgrade cluster to OCP3.9, v3.9.0-0.24.0 > > Does this step restart the master? i.e. a master reboot is _always_ > required after an upgrade. Chuan, can you clarify the exact steps for #2?
Matt, the steps is restart master service, atomic-openshift-master-api.service and atomic-openshift-master-controllers.service.
Chuan, I meant to ask for details (commands run, verbose outputs, etc.) on the steps you are taking for the whole upgrade process. The upgrade steps that I see in the docs mention that you need to the restart manually, or reboot the master after an automated upgrade, so I don't think the restart is intended to be an integrated part of the upgrade.
The master logs throughout the upgrade process will also be helpful here (so pre-, during, and post- logs).
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