Not sure about the service catalog+ASB, but for the TSB it seems like the apiserver-template.yaml needs to be reapplied w/ a new $IMAGE parameter value.
(In reply to Ben Parees from comment #1)
> Not sure about the service catalog+ASB, but for the TSB it seems like the
> apiserver-template.yaml needs to be reapplied w/ a new $IMAGE parameter
I reported a bug  about TSB upgrade issue, it still use ose:v3.7 after upgrade, but the apiserver-template.yaml for installer has been updated to use new image :https://github.com/openshift/openshift-ansible/blob/master/roles/template_service_broker/files/apiserver-template.yaml#L7 and it is also using new image in fresh install.
> but the apiserver-template.yaml for installer has been updated to use new image
well it shouldn't be using latest, but i assume the IMAGE parameter is getting substituted properly on a fresh install which is why it's ok for you on a new install. Anyway we'll chase the TSB side of this in your bug 1540521.
i suggest you open separate bugs for the SC and ASB as well. Scott may be the coordinator but each component team probably needs to be involved.
I'm changing title to "ansible service broker still using ocp3.7 images after upgrade to ocp3.9" for separate issues.
And, I hope to trace asb side in here. And submitted another bug 1541247 to trace service-catalog side. Thanks.
To fix this we need to
1) Land Vadim's changes so that the image tag for service catalog, tsb, etc matches the master image tag
2) Audit service catalog, tsb, asb roles to ensure that re-running their install tasks use `oc process | oc apply` to re-apply the new templates.
3) make sure we are actually rerunning their install tasks on upgrade
PR Created: https://github.com/openshift/openshift-ansible/pull/7251
The ASB switch depends on the service catalog, changed the status to "MODIFIED" since have a blocking bug 1547803. Not ready for a test.
The openshift-ansible version:
The tag of the ASB image is still the "v3.7" after an upgrade.
It looks like this change has not yet made it to a tag:
I ran it through a few times locally with the latest release-3.9 and was unable to reproduce this bug, I think once the above PR is tagged in we'll be fine.