Implicit architecture constraints prevent easy deployment on non-amd64

Juju has an implicit constraint for architecture every time a constraint is set, so when we use something like "mem=8G", we automatically get "mem=8G arch=amd64" (unless we explicitly give an different arch constraint).

This requires manual intervention when deploying charmed-kubernetes in a non-x86 architectures; for example, when deploying to a local LXD cloud in s390, the documented way will fail:

ubuntu@s1lp13:~$ juju deploy charmed-kubernetes
Located bundle "charmed-kubernetes" in charm-hub, revision 1009
Located charm "calico" in charm-hub, channel stable
Located charm "containerd" in charm-hub, channel stable
Located charm "easyrsa" in charm-hub, channel stable
Located charm "etcd" in charm-hub, channel stable
Located charm "kubeapi-load-balancer" in charm-hub, channel stable
Located charm "kubernetes-control-plane" in charm-hub, channel stable
Located charm "kubernetes-worker" in charm-hub, channel stable
Executing changes:
- upload charm calico from charm-hub for series focal from channel latest/stable with architecture=amd64
- deploy application calico from charm-hub on focal with latest/stable
  added resource calico
  added resource calico-arm64
  added resource calico-node-image
- set annotations for calico
- upload charm containerd from charm-hub for series focal from channel latest/stable with architecture=amd64
- deploy application containerd from charm-hub on focal with latest/stable
- set annotations for containerd
- upload charm easyrsa from charm-hub for series focal from channel latest/stable with architecture=amd64
- deploy application easyrsa from charm-hub on focal with latest/stable
ERROR cannot deploy bundle: cannot deploy application "easyrsa": cannot add application "easyrsa": invalid constraint value: arch=amd64
valid values are: [s390x]

Typical workaround is updating the charm bundle to add the explicit constraints, with these changes:

ubuntu@s1lp13:~/bundle/releases/1.23$ git diff
diff --git a/releases/1.23/bundle.yaml b/releases/1.23/bundle.yaml
index b08344b..4dde4e8 100644
--- a/releases/1.23/bundle.yaml
+++ b/releases/1.23/bundle.yaml
@@ -12,7 +12,7 @@ applications:
       gui-x: '90'
       gui-y: '420'
     charm: cs:~containers/easyrsa-441
- constraints: root-disk=8G
+ constraints: root-disk=8G arch=s390x
     num_units: 1
     resources:
       easyrsa: 5
@@ -21,7 +21,7 @@ applications:
       gui-x: '800'
       gui-y: '420'
     charm: cs:~containers/etcd-655
- constraints: root-disk=8G
+ constraints: root-disk=8G arch=s390x
     num_units: 3
     options:
       channel: 3.4/stable
@@ -43,7 +43,7 @@ applications:
       gui-x: '450'
       gui-y: '250'
     charm: cs:~containers/kubeapi-load-balancer-866
- constraints: mem=4G root-disk=8G
+ constraints: mem=4G root-disk=8G arch=s390x
     expose: true
     num_units: 1
     resources: {}
@@ -52,7 +52,7 @@ applications:
       gui-x: '800'
       gui-y: '850'
     charm: cs:~containers/kubernetes-master-1106
- constraints: cores=2 mem=4G root-disk=16G
+ constraints: cores=2 mem=4G root-disk=16G arch=s390x
     num_units: 2
     options:
       channel: 1.23/stable
@@ -72,7 +72,7 @@ applications:
       gui-x: '90'
       gui-y: '850'
     charm: cs:~containers/kubernetes-worker-838
- constraints: cores=4 mem=4G root-disk=16G
+ constraints: cores=4 mem=4G root-disk=16G arch=s390x
     expose: true
     num_units: 3
     options:
ubuntu@s1lp13:~/bundle/releases/1.23$

... and deploy from the updated local copy.

However, this workaround is not obvious for people who are not used to this juju behavior.

We can change the "bundle" script to add the constraints automatically every time the bundle is generated; so we ca instruct the users of non-amd64 architectures to download that repo and create their own bundle for deployment. *Or* we can publish special bundles for non-x64, instructing the uses to run "juju deploy chamred-kubernetes-s390x" (or similar).

I already did a few changes to the script as an experiment, but I'm not sure if this is the best way to go. Any ideas?