thanks alot
My openstack re-deploy also failed with this error, so a reverted JUJU back to 2.8:
root@juju2:~/devops/bin/openstack/engstack4# snap list juju
Name Version Rev Tracking Publisher Notes
juju 2.8.13 17665 2.8/stable canonical✓ classic
But the problem persists:
ERROR cannot deploy bundle: cs:mysql-innodb-cluster-8 resource "mysql-shell": bad metadata: resource missing filename
This is the same bundle and overlay I used about a year ago and now I need to re-deploy it (Wallaby). I went down the path of switching mysql from cs to ch:
< charm: cs:mysql-router-8
---
> charm: ch:mysql-router
> channel: 8.0/stable
in about 10 places, but that lead to a while new set of issues. Do I need to go back to an even older version of Juju? I really need this testbed back to the way it was last time I deployed it. I thought by archiving the bundle and overlay, I would have no problems re-deploying so I didn’t think twice about tearing down this openstack install so I could use the machines for another project. Is there some guidance on everything that needs to be captured? I did not touch the MAAS server and I didn’t think we had touched the JUJU server, but it looks like SNAP may have updated juju for me.
I recommend you use Juju 2.9.x and the 8.0 channel for the MySQL charms. If I understand correctly you have not tried this?
I did try that.
-
juju 2.9 + cs:mysql-router-8 failed
-
juju 2.9 + ch:mysql-router channel 8.0/stable failed
-
juju 2.8.13 + cs:mysql-router-8 failed
-
juju 2.8.10 + cs:mysql-router-8 failed:
ERROR cannot deploy bundle: bad metadata: resource missing filename
Is it okay to mix cs: and ch: in a single bundle? I only switched mysql-router-* and mysql-innodb-cluster
Mixing should be OK but it is not ideal.
Juju 2.9 and MySQL channel 8.0 should definitely work.
What output do you get for:
juju status mysql-innodb-cluster keystone-mysql-router
Do you see anything suspicious with:
juju debug-log --replay --no-tail -i mysql-innodb-cluster/0juju 2.9.31
mysql-innodb-cluster and *-mysql-router are using
charm: ch:mysql-router
channel: 8.0/stable
I don’t understand the reference to relation “database”. When I include --relations, I don’t see anything labeled “database”
root@juju2:~/devops/bin/openstack/engstack4# juju status mysql-innodb-cluster keystone-mysql-router
Model Controller Cloud/Region Version SLA Timestamp
engstack4 maas3-default maas3/default 2.9.31 unsupported 21:30:45Z
App Version Status Scale Charm Channel Rev Exposed Message
keystone 19.0.0 waiting 1 keystone stable 323 no Allowed_units list provided but this unit not present
keystone-mysql-router 8.0.29 waiting 1 mysql-router 8.0/stable 30 no 'db-router' incomplete, MySQL Router not yet bootstrapped
mysql-innodb-cluster 8.0.29 active 3 mysql-innodb-cluster 8.0/stable 26 no Unit is ready: Mode: R/O, Cluster is ONLINE and can tolerate up to ONE failure.
Unit Workload Agent Machine Public address Ports Message
keystone/0* blocked idle 0/lxd/1 10.23.0.16 5000/tcp Incomplete relations: database, Allowed_units list provided but this unit not present
keystone-mysql-router/0* waiting executing 10.23.0.16 'db-router' incomplete, MySQL Router not yet bootstrapped
mysql-innodb-cluster/0 active idle 1/lxd/1 10.23.0.26 Unit is ready: Mode: R/O, Cluster is ONLINE and can tolerate up to ONE failure.
mysql-innodb-cluster/1 active idle 2/lxd/2 10.23.0.28 Unit is ready: Mode: R/O, Cluster is ONLINE and can tolerate up to ONE failure.
mysql-innodb-cluster/2* active idle 3/lxd/2 10.23.0.21 Unit is ready: Mode: R/W, Cluster is ONLINE and can tolerate up to ONE failure.
Machine State DNS Inst id Series AZ Message
0 started 10.22.0.1 grunt107 focal default Deployed
0/lxd/1 started 10.23.0.16 juju-b5cd12-0-lxd-1 focal default Container started
1 started 10.22.0.5 grunt10 focal default Deployed
1/lxd/1 started 10.23.0.26 juju-b5cd12-1-lxd-1 focal default Container started
2 started 10.22.0.4 grunt8 focal default Deployed
2/lxd/2 started 10.23.0.28 juju-b5cd12-2-lxd-2 focal default Container started
3 started 10.22.0.6 grunt9 focal default Deployed
3/lxd/2 started 10.23.0.21 juju-b5cd12-3-lxd-2 focal default Container startedIs there a better way to post code snippets that are this wide? Should this be its own ticket?
Hi Jeremy,
Regarding the code snippets, I think that’s fine how you did it. Regarding your issue, juju status --relations shows you the current relations that are active between the charms. Since you’re missing the database relation, you won’t see it there. To see a list of possible relations that exist for a specific charm, you can do juju info keystone and you’ll see a section like this :
relations:
provides:
identity-admin: keystone-admin
identity-credentials: keystone-credentials
identity-notifications: keystone-notifications
identity-service: keystone
nrpe-external-master: nrpe-external-master
requires:
certificates: tls-certificates
domain-backend: keystone-domain-backend
ha: hacluster
keystone-fid-service-provider: keystone-fid-service-provider
keystone-middleware: keystone-middleware
shared-db: mysql-shared
websso-trusted-dashboard: websso-trusted-dashboard
So the keystone charm has a shared-db relation endpoint, that can be attached to the mysql-innodb-cluster application. If you add that relation, I think it’ll solve your current issue.
juju add-relation keystone:shared-db mysql-innodb-cluster:shared-db.
I can’t see if you’ve related the keystone-mysql-router to the cluster with what you’ve provided, so just to make sure, run this as well :
juju add-relation keystone-mysql-router:db-router mysql-innodb-cluster:db-router
Hope this helps ! You can also take a look at the Openstack Base bundle that already has all these relations set up for a basic openstack deployment Deploy Openstack Base using Charmhub - The Open Operator Collection
Shouldn’t the shared-db connection be from keystone to keystone-mysql-router and then a db-router connection from keystone-mysql-router to mysql-innodb-cluster? Here’s the relevant sections from the Wallaby bundle?
- - keystone:shared-db
- keystone-mysql-router:shared-db
...
- - keystone-mysql-router:db-router
- mysql-innodb-cluster:db-routerAh yeah I got mixed up 
anyhow, do you have these relations currently applied ? Did that fix your issue?
keystone started crashing and got stuck in maintenance mode.
I’m going to try a new path … setting all charms to use latest/stable instead. If that blows up, I’ll come back to this, but I am frustrated that they bundle and overlay that I saved last year no longer work. I know there a lot of moving parts, but I still feel like that shouldn’t happen.
back to the suggestion that I use mysql-router 8.0/latest. This seems to require a new relationship “juju-info” and I can’t find a version of keystone that provides juju-info. Any suggestions?
The deploy-guide explains well how an application is joined to the cloud database. It does so using the vault application as an example.
You need not worry about juju-info at all.
I’m not sure that’s true. see Juju-log Unable to find implementation for relation: requires of juju-info - Charmhub
I’m stuck on juju-info … although that could be a bug in mysql 8.0/stable
juju_info was a red herring. It is not an issue.
The solution was to use ch:mysql-router and ch:mysql-innodb-cluster and channel 8.0 stable AND set all units to use one network space for everything. Perhaps that was overkill, but at least I have a successful deployment now using my original bundle with only mysql tweaked and a new overlay.
FYI mixing cs:mysql-router-xxx and ch:mysql-router 8.0/stable failed in weird ways (mysql-router throwing exceptions).
Thanks to all the people that offered advice.
Awesome. I’m glad you got it to work!
Thank you for your work on this open source project.
I’m very frustrated with what should be a no brainer operation that has worked in the past.
I’m experiencing the same issues. No change on our part but the deployment infrastructure at charm whatever seems to break my deployment attempts. It seems like breaking changes are being applied to existing versioned resources or something is silently upgrading behind the scenes before it’s ready for prime time.
Its very frustrating that the deployment services seem to be treated like a test bed.
As an example, soon after installing Juju for the first time, juju GUI image artifacts started returning 404. Juju GUI image artifacts have been broken for several months now.
Is the solution to the mysql issue to use CH instead of CS? What’s the difference? Where is the info that details this change?
Thanks for your help and support.
Hi, this problem was exceptionally caused by a change in track number for the MySQL charms (8.0.19 to 8.0) in combination with how Launchpad charm building handles charm resources.
Deploy/upgrade charms mysql-router and mysql-innodb-cluster to channel 8.0/stable. So, yes, use the Charmhub (ch) via the ch: prefix.
To deploy:
juju deploy --channel 8.0/stable ch:mysql-router ...
juju deploy --channel 8.0/stable ch:mysql-innodb-cluster ...This fixed my deployment problem!
Thanks!
1 Like