Heterogeneous application architectures in the same model

[Simon Richardson]

With the new implementation of CharmHub API and the placement of applications within a given model, the application architecture has to be Homogeneous. Does an application have many charms, or charms have many architectures?

How do we refresh a charm considering there are potentially many of them, what if one is missing in the future, do all upgrade or none or do we have a partial upgrade?

[John A Meinel (jameinel)]

I think ultimately we went with you have multiple applications if you have multiple architectures.
There are times when this isn't very satisfying, but it does fit the current modeling. We can look to come back in the future if we get to a point where we have an abstracted view of a "version of the charm" across multiple architectures, but that doesn't exist today.

[Stéphane Graber (stgraber)]

Hmm, maybe I'm missing something, but isn't that an insane amount of logic to put in each charm just to workaround a Juju regression?

Our use case is for LXD cloud where we want it to be able to deploy a rack with say 15 machines, 5 of those being amd64, 5 of those being arm64 and 5 of those being ppc64el. All of those must be clustered as a single LXD cluster so it can be added to a LXD cloud cell and region.

This is very similar to how Scalingstack is deployed today at Canonical, so needing a cloud to be multi-architecture isn't exactly unheard of.

Currently with a single application, it's easy, we deploy the LXD charm across all 15 machines with the mode=cluster config set. This causes the leader to bootstrap the cluster, issue credentials for the other 14 systems and cluster them all together through peer relations.

Now if we're dealing with 3 apps. We end up with 3 completely separate LXD clusters, one per architecture. This isn't the result we want at all.

To workaround that, we'd then need to have logic to deploy one application normally as a cluster, then the other two applications need to be deployed in a different mode, not cluster, not standalone but some kind of cluster-join mode which would then rely on a relation between that application and the first application so they can get the credentials needed to join the cluster.

That's not impossible but would pretty much double the complexity of the LXD charm and also make things incredibly brittle as it would now force us to build a layer on top of Juju to ensure that configuration keys and relations are all applied consistently across all applications.

[Simon Fels (morphis)]

To be precise not having multi-arch support in an application is a regression which has been introduced with the switch to Charmhub in the 2.9 series. In our case we had customers who actually had deployed LXD on different architectures which was not possible anymore when we switched to Charmhub. They had to do different deployments to have multi-architecture support for their use case.

I agree with Stephane that letting charms handle this is not suitable. This is adding a ton of complexity to an already complex model of managing relations and cluster formation. The implementation has to deal with various edge cases which Juju often doesn't make really easy to deal with. Adding another relation to the same charm just under a different name isn't going to make this simpler and is just a hack from my point of view.