kube-apiserver can be deployed without cert-syncer having a valid token. This ca be caused by a race when making revisions from token Secret as in https://bugzilla.redhat.com/show_bug.cgi?id=1819256
Due to pushed by PM/Dev for backport but daylight has no time, working at night: Checked the commit https://github.com/openshift/cluster-kube-apiserver-operator/pull/815/commits/e83b8303911b286fa6eea4dde5ded2fc0bf555ec#diff-dd9e4bf75a3b418978ce9d66ec26cfadR351 , and PR https://github.com/openshift/library-go/pull/764/files change. Saw bug 1819256#c3 which needs to rollout the static pods, but each rollout will take 5 mins, all verification time will spend 5 * loop_count mins, not viable. So just verify via the test code in 4.5.0-0.nightly-2020-04-13-213244: === RUN TestSyncSecret === RUN TestSyncSecret/syncing_existing_secret_succeeds_when_the_target_is_missing === RUN TestSyncSecret/syncing_existing_secret_succeeds_when_the_target_is_present_and_up_to_date === RUN TestSyncSecret/syncing_existing_secret_succeeds_when_the_target_is_present_and_needs_update === RUN TestSyncSecret/syncing_missing_source_secret_doesn't_fail === RUN TestSyncSecret/syncing_service_account_token_doesn't_sync_without_the_token_being_present === RUN TestSyncSecret/syncing_service_account_token_strips_"managed"_annotations --- PASS: TestSyncSecret (0.00s) --- PASS: TestSyncSecret/syncing_existing_secret_succeeds_when_the_target_is_missing (0.00s) --- PASS: TestSyncSecret/syncing_existing_secret_succeeds_when_the_target_is_present_and_up_to_date (0.00s) --- PASS: TestSyncSecret/syncing_existing_secret_succeeds_when_the_target_is_present_and_needs_update (0.00s) --- PASS: TestSyncSecret/syncing_missing_source_secret_doesn't_fail (0.00s) --- PASS: TestSyncSecret/syncing_service_account_token_doesn't_sync_without_the_token_being_present (0.00s) --- PASS: TestSyncSecret/syncing_service_account_token_strips_"managed"_annotations (0.00s) PASS ok github.com/openshift/library-go/pkg/operator/resource/resourceapply 0.013s
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-2020:2409