This is an interesting use case. I'm not sure whether to mark this as invalid or wishlist.
The charms certainly weren't designed to support mixed versions of percona-cluster (mysql) in a single cluster. Xenial is percona-xtradb-cluster-server-5.5 and bionic is percona-xtradb-cluster-server-5.7 (unless you have upgraded it using a PPA to 5.7?)
More importantly, I don't know what the charms themselves will do with some of them on xenial and some of them on bionic. There are definitely different code-paths for xenial and bionic handling in the charm.
So if you can't do a release-upgrade from xenial->bionic, then realistically launching a new cluster on bionic and then dump/restore would seem (currently) to be the preferred approach.
Do you envisage many systems where this would be the only upgrade path (i.e. gradual replace rather than release-upgrade on unit)?
This is an interesting use case. I'm not sure whether to mark this as invalid or wishlist.
The charms certainly weren't designed to support mixed versions of percona-cluster (mysql) in a single cluster. Xenial is percona- xtradb- cluster- server- 5.5 and bionic is percona- xtradb- cluster- server- 5.7 (unless you have upgraded it using a PPA to 5.7?)
More importantly, I don't know what the charms themselves will do with some of them on xenial and some of them on bionic. There are definitely different code-paths for xenial and bionic handling in the charm.
So if you can't do a release-upgrade from xenial->bionic, then realistically launching a new cluster on bionic and then dump/restore would seem (currently) to be the preferred approach.
Do you envisage many systems where this would be the only upgrade path (i.e. gradual replace rather than release-upgrade on unit)?