Ideally we have 2 mechanisms to handle APB compatibility. 1) Tag APBs with a known tag, say v3.7 for downstream. Then Broker is configured to use tag v3.7 with the registry configuration so it only pulls the desired images. (sprint141 for example with upstream) 2) Broker should be able to determine compatibility with an APB and skip the incompatible images during the bootstrap operation. APB should have sufficient info in metadata so Broker can determine if it can execute. Sounds like we need to re-examine our approach for #2 and how we are handling it. In the reported problem we would want the Broker to skip (and log it is skipping) the updated APBs if they are not compatible.
The problem in this bug is that you are using new APBs (runtime=2) with an old Service Broker. A Service Broker that 1) Does not pass along the POD_NAME/POD_NAMESPACE to the apb and 2) Does not know how to handle APBs of different runtimes. We likely just need to update our downstream images. Once the downstream broker knows how to handle runtime=2 APBs, it will also be backwards compatible with older APBs (runtime=1).
Downstream builds for the broker and apbs should now be updated.