juju deploys an amd64 charm if --arch=arm64 is specified (and no arm64 version is available in that channel)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
High
|
Unassigned | ||
Snap Store Server |
New
|
Undecided
|
Unassigned |
Bug Description
Juju should refuse to deploy a charm if the architecture isn't supported. Currently if you try to deploy an arm64 postgresql-k8s it will end up deploying the amd64 variant, and have it just break.
When juju does `juju deploy postgresql-k8s --arch=arm64` it does a Refresh like:
```
$ curl -X POST -H 'Content-type: application/json' -s https:/
```
However, because the store treats that as 'return all the bases that you have', Charmhub then returns a bunch of bases that are amd64 only:
```
{
"error-list": [],
"results": [
{
"charm": null,
"error": {
"code": "revision-
"extra": {
{
},
},
{
},
},
{
},
},
{
},
},
{
},
},
{
},
},
{
},
},
{
},
}
]
},
"message": "No revision was found in the Store."
},
"id": "qOZHieOsemJO4N
"
"name": "kubeflow-roles",
"
"result": "error"
}
]
}
```
Likely Juju needs to be filtering the response from Refresh so that it ignores bases that aren't the right architecture. (This might also be fixed in Snapstore by having them filter it)
Changed in juju: | |
milestone: | 2.9-next → none |
summary: |
- juju deploys an amd64 charm if --arch=arm64 is specified + juju deploys an amd64 charm if --arch=arm64 is specified (and no arm64 + version is available in that channel) |