Currently the process for deploying where we came across this issue is:
deploy openstack and bring it fully up with charm actions etc.
deploy lma in separate model
relate lma charms to openstack by redeploying the openstack with saas relations to the lma bits (telegraph, filebeat, landscape client).
I actually notice that 2 of the cases of it happening are on the stable charms.
And with some further digging, it looks like we're missing the version pinning during the lma re-deploy. so the charm is upgrading from revision 2 to revision 3.
Also removing the release blocker tag, since upgrade isnt part of the release gate.
This doesnt happen every run, but it has happened more than once. /solutions. qa.canonical. com/bugs/ bugs/bug/ 1912820
you can see all the times it's happened here:
https:/
Currently the process for deploying where we came across this issue is:
deploy openstack and bring it fully up with charm actions etc.
deploy lma in separate model
relate lma charms to openstack by redeploying the openstack with saas relations to the lma bits (telegraph, filebeat, landscape client).
I actually notice that 2 of the cases of it happening are on the stable charms.
And with some further digging, it looks like we're missing the version pinning during the lma re-deploy. so the charm is upgrading from revision 2 to revision 3.
Also removing the release blocker tag, since upgrade isnt part of the release gate.