bootstrapping against openstack adds implicit arch=amd64 constraint

[Jason Hobbs]

This is with juju 2.2.2.

When running from an amd64 host (client), bootstrapping against an OpenStack with only arm64 hypervisors fails, because juju implicitly adds an 'arch=amd64' bootstrap constraint.

If I don't specify an arch constraint, juju shouldn't assume one. If it needs to know what architecture is needed for the agent, it can ask OpenStack what the hypervisors support.

I can workaround this by adding an explicit --bootstrap-constraints arch=arm64. This pastebin shows both cases:
http://paste.ubuntu.com/25341833/

[Tim Penhey (thumper)]

To be honest I don't think it is just openstack that has this implicit constraint.

[Jamon Camisso (jamon)]

I ran into this as well when trying to add units to a model to test mixed CPU architectures.

The really strange thing is I could always add an amd64 unit.

For example: start with an empty model and specify a constraint for a different architecture e.g. ppc64el. Any new unit/machine will complain if you try specifying something like arm64.

To change the architecture, first add another throwaway amd64 unit or machine (and then remove it).

From there you can add a unit or machine with a different architecture constraint again, e.g. arm64.

Very strange indeed!

[Marian Gasparovic (marosg)]

I am hitting this in 2022.
My openstack is deployed on arm machines, juju bootstrap on top of openstack with arch=arm64.

Case 1 - when no constraint is used, juju assumes amd64
$ juju deploy cs:~containers/kubernetes-worker k8sw1
Located charm "kubernetes-worker" in charm-store, revision 838
Deploying "k8sw1" from charm-store charm "kubernetes-worker", revision 838 in channel stable

Case 2 - arm64 constraint specified explicitely, all is fine
$ juju deploy cs:~containers/kubernetes-worker k8sw2 --constraints arch=arm64
Located charm "kubernetes-worker" in charm-store, revision 838
Deploying "k8sw2" from charm-store charm "kubernetes-worker", revision 838 in channel stable

Case 3 - different constraint is specified, arch is again assumed to be amd64
$ juju deploy cs:~containers/kubernetes-worker k8sw3 --constraints mem=8G
Located charm "kubernetes-worker" in charm-store, revision 838
Deploying "k8sw3" from charm-store charm "kubernetes-worker", revision 838 in channel stable

results

Model Controller Cloud/Region Version SLA Timestamp
kubernetes foundation-openstack openstack_cloud/RegionOne 2.9.22 unsupported 16:07:40Z

App Version Status Scale Charm Store Channel Rev OS Message
k8sw1 waiting 0/1 kubernetes-worker charmstore stable 838 ubuntu waiting for machine
k8sw2 1.23.3 blocked 1 kubernetes-worker charmstore stable 838 ubuntu Missing relation to certificate authority.
k8sw3 error 0/1 kubernetes-worker charmstore stable 838 ubuntu cannot assign unit "k8sw3/0" to machine: cannot assign unit "k8sw3/0" to new machine or container: cannot assign unit "k8sw3/0" to new machine: invalid constraint value: arch=amd64
valid values are: [arm64]

Unit Workload Agent Machine Public address Ports Message
k8sw1/0 waiting allocating 0 waiting for machine
k8sw2/0* blocked idle 1 10.246.204.115 Missing relation to certificate authority.
k8sw3/0 error lost cannot assign unit "k8sw3/0" to machine: cannot assign unit "k8sw3/0" to new machine or container: cannot assign unit "k8sw3/0" to new machine: invalid constraint value: arch=amd64
valid values are: [arm64]

Machine State DNS Inst id Series AZ Message
0 down pending focal no metadata for "focal" images in RegionOne with arches [amd64]
1 started 10.246.204.115 7efd2efe-c746-4557-a9ba-afacfaaefbb3 focal nova ACTIVE

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.