With the original hive rolling deployment for OSD, hive could periodically re-vendor the openshift-install code to perform a deprovision. With a non-rolling hive release (as is used in ACM), periodically re-vendoring openshift-install doesn't help the following use-case:

ACM 2.3 installs an OpenShift 4.8 cluster
The cluster is then upgraded to some future post-4.8 release (not a z-stream)
User then tries to deprovision the cluster, but the version of hive has not been updated to know about future cloud/platform resources that are new to OpenShift 4.8+
Hive either errors out because it couldn't delete some cloud resource (due to dependency errors), or hive completes deprovisioning but leaks cloud resources

Modify hive to treat deprovision much like provisioning a cluster. Pull the "latest" version of the openshift-install image (since openshift-install is backwards compatible when it comes to deprovisioning older cluster versions). <--- we should double check with the installer team about this

Allow a way for hive to be told to use an alternative "deprovision" image to accommodate the use case where hive is being run in a disconnected networking environment where we can't fetch the "latest" images.