Model default series is not honoured - wrong series gets deployed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Simon Richardson | ||
Snap Store Server |
Fix Released
|
High
|
Guillermo Gonzalez |
Bug Description
When a default series is set on the model it is not honoured during the deployment of a charm. Some other series gets deployed instead. This only appears to affect the new charm store; the old charm store is fine.
$ juju add-model --config default-
$ juju deploy ch:nova-compute nova-compute-ch-def
$ juju deploy cs:nova-compute nova-compute-cs-def
$ juju status
Model Controller Cloud/Region Version SLA Timestamp
openstack serverstack serverstack/
App Version Status Scale Charm Store Channel Rev OS Message
nova-compute-ch-def waiting 0/1 nova-compute charmhub stable 539 ubuntu waiting for machine
nova-compute-cs-def waiting 0/1 nova-compute charmstore stable 327 ubuntu waiting for machine
Unit Workload Agent Machine Public address Ports Message
nova-compute-
nova-compute-
Machine State DNS Inst id Series AZ Message
0 pending 10.5.0.7 f4c76b44-
1 pending 10.5.0.8 7fbeaad4-
Changed in juju: | |
milestone: | 2.9.2 → 2.9.3 |
Changed in juju: | |
assignee: | nobody → Simon Richardson (simonrichardson) |
status: | Triaged → In Progress |
Changed in snapstore-server: | |
importance: | Undecided → High |
assignee: | nobody → Guillermo Gonzalez (verterok) |
Changed in snapstore-server: | |
status: | Confirmed → In Progress |
Changed in snapstore-server: | |
status: | In Progress → Fix Committed |
Changed in juju: | |
status: | In Progress → Fix Committed |
Changed in juju: | |
status: | Fix Committed → Fix Released |
Changed in snapstore-server: | |
status: | Fix Committed → Fix Released |
So, the revision of the charm is correct (539 is the latest in charmhub, and should map to 327 on charmstore). The charm payload actually is the same and does support focal.
In the two-phase request that Juju makes, it first does an "invalid base" request, and in here the charmhub API *is* reporting xenial as the sole available base:
$ curl -XPOST -s https:/ /api.charmhub. io/v2/charms/ refresh -H 'Content-type: application/json' -d '{"context": [], "actions": [{"name": "nova-compute", "base": {"architecture": "amd64", "name": "NA", "channel": "NA"}, "channel": "stable", "action": "install", "instance-key": "a-test"}]}' | jq charm-base" ,
"default- bases": [
"architecture" : "amd64",
"channel" : "16.04",
"name": "ubuntu" ubPbvtErosR9P4N GEt24wak8LDsczR i4 name=nova-compute" NGEt24wak8LDscz Ri4", instance- key": "a-test", released- at": null,
{
"error-list": [],
"results": [
{
"charm": null,
"error": {
"code": "invalid-
"extra": {
{
}
]
},
"message": "Instance key 'a-test' invalid 'base' in 'install' for charm_id=
},
"id": "ubPbvtErosR9P4
"
"name": "nova-compute",
"
"result": "error"
}
]
}
then Juju uses that as the series to deploy.
We'll have a closer look at how the available bases are calculated for this snap.