juju adds constraints e.g. "arch=amd64" during deployment
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Medium
|
Unassigned |
Bug Description
I get this when I dry-run juju-deploy over the deployed model. Since I did not modify my bundle, the dry-run should not return anything.
$juju deploy -m openstack ./bundle.yaml --dry-run
Changes to deploy bundle:
- set constraints for aodh to ""
$ juju get-constraints aodh
arch=amd64
(this happens to other apps as well, where arch=amd64 constraints were not set in the bundle, including nova-compute)
juju version: 2.9.32
OpenStack cloud, juju sets the constraints on apps deployed on KVM as well as bare-metal.
Reproduction steps:
$juju deploy -m openstack ./bundle.yaml --dry-run #over deployed model
Or simply don't include the constraint in the bundle and then run $ juju get-constraints <application>
Changed in juju: | |
milestone: | 2.9.35 → 2.9.36 |
Changed in juju: | |
milestone: | 2.9.36 → 2.9.37 |
Changed in juju: | |
milestone: | 2.9.37 → 2.9.38 |
Changed in juju: | |
milestone: | 2.9.38 → 2.9.39 |
Changed in juju: | |
milestone: | 2.9.39 → 2.9.40 |
Changed in juju: | |
milestone: | 2.9.40 → 2.9.41 |
Changed in juju: | |
milestone: | 2.9.41 → 2.9.42 |
Changed in juju: | |
milestone: | 2.9.42 → 2.9.43 |
Changed in juju: | |
milestone: | 2.9.43 → 2.9.44 |
Changed in juju: | |
milestone: | 2.9.44 → 2.9.45 |
Changed in juju: | |
milestone: | 2.9.45 → 2.9.46 |
The issue here is that with the transition to charmhub, there can be different blobs served for different architectures. It previous didn't matter with charmstore as there was just the one charm blob for any arch.
charmhub requires that an architecture *must* be specified when asking for a charm or else it doesn't know which one to serve up. So juju will default to "amd64". That's what's happening with the bundle - no arch is specified.
The above issue affects various places in the code where an empty arch is compared to the juju supplied default. bundle --dry-run looks like it's one of those places which needs looking at.
You can avoid the issue by explicitly specifying amd64 in the bundle.