So what is really happening is this (and it's not "necessarily" a bug). I'll update the title to reflect this.
The nova-cloud-controller charm AT stein will not upgrade unless placement is related to the unit. If it is not, then the upgrade bails out. At this stage config-changed is done, i.e. it's now at "cloud:bionic-train".
If the placement charm is then related to the unit, it removes the blocked state but won't actually work. i.e. nova-cloud-controller is still at stein with a placement at train (probably). If nova-compute is upgraded to train then the error occurs.
Possible changes are:
* Detect in the update-status that the config for openstack-origin doesn't match the version installed, and show a blocked message.
* On relating the charm to placement do the upgrade (assuming action-managed-upgrade is false) to ensure that the charm is at the version of openstack-origin that the config says it should be (along with action-managed-upgrade being false).
I think the first option is useful *anyway* as config not matching payload status IS a blocking or error condition.
So what is really happening is this (and it's not "necessarily" a bug). I'll update the title to reflect this.
The nova-cloud- controller charm AT stein will not upgrade unless placement is related to the unit. If it is not, then the upgrade bails out. At this stage config-changed is done, i.e. it's now at "cloud: bionic- train".
If the placement charm is then related to the unit, it removes the blocked state but won't actually work. i.e. nova-cloud- controller is still at stein with a placement at train (probably). If nova-compute is upgraded to train then the error occurs.
Possible changes are:
* Detect in the update-status that the config for openstack-origin doesn't match the version installed, and show a blocked message. managed- upgrade is false) to ensure that the charm is at the version of openstack-origin that the config says it should be (along with action- managed- upgrade being false).
* On relating the charm to placement do the upgrade (assuming action-
I think the first option is useful *anyway* as config not matching payload status IS a blocking or error condition.
I'll update the title to reflect this issue.