Hi,
We hare recently release 8.0/stable and would like to switch the default track from latest to 8.0 (to close track latest).
Can you please switch default tracks for charms:
- mysql
- mysql-k8s
Thank you!
1 Like
This is done 
- Daniel
1 Like
Would you expect that this should work now?
$ juju deploy mysql-k8s
ERROR selecting releases: charm or bundle not found for channel "", platform "amd64"
available releases are:
channel "candidate": available series are: focal
channel "beta": available series are: focal
channel "edge": available series are: jammy, focal
channel "8.0/stable": available series are: jammy
channel "8.0/candidate": available series are: jammy
channel "8.0/beta": available series are: jammy
channel "8.0/edge": available series are: jammy
ERROR selecting releases: charm or bundle not found for channel “” …
I have noticed the same problem yesterday late, but didn’t report it hoping it is some temporary synchronization issue. The issue is reproducible with mysql/mysql-k8s and mongodb charms (using juju 2.9 and juju 3.1).
P.S. All risks in the latest tracks are closed for all three charms mentioned above and defaults are switched to numeric track.
P.P.S Is it a charmhub of juju issue? E.g. this works: juju deploy mysql --series jammy # o_0
If you look at the response for mysql-k8s and another random charm (influxdb in this case) you will see the response is not structurally different. In both cases, and since with a plain juju deploy we don’t know which base to install under, Juju first requests a list of available bases by passing a conventional, invalid base:
curl -XPOST -s https://api.charmhub.io/v2/charms/refresh -H 'Content-type: application/json' -d '{ "context": [], "actions": [{"name": "mysql", "base": {"name": "ubuntu", "channel": "NA", "architecture": "NA"} , "channel": "stable" , "action": "install", "instance-key": "a-test"}]}' | jq .
versus
curl -XPOST -s https://api.charmhub.io/v2/charms/refresh -H 'Content-type: application/json' -d '{ "context": [], "actions": [{"name": "influxdb", "base": {"name": "ubuntu", "channel": "NA", "architecture": "NA"} , "channel": "stable" , "action": "install", "instance-key": "a-test"}]}' | jq .
If I remember correctly, Juju will by default choose the first base in the list given, and do a second request later with that concrete base, which charmhub will reply to with a specific revision to install.
This is what the “invalid base” lists look like for these charms. For influx:
{
"error-list": [],
"results": [
{
"charm": {
"id": "02GijI3Vx8wTe63c7uUrNQGovCdt4x9t",
"license": "",
"name": "influxdb",
"publisher": {
"display-name": "InfluxDB Charmers",
"id": "y8mze7pW8pg0PjJK24reeJ0wfnis2lCL",
"username": "influxdb-charmers",
"validation": "unproven"
},
"summary": "Scalable Time Series DB",
"type": "charm"
},
"error": {
"code": "revision-not-found",
"extra": {
"releases": [
{
"base": {
"architecture": "amd64",
"channel": "20.04",
"name": "ubuntu"
},
"channel": "stable"
},
{
"base": {
"architecture": "amd64",
"channel": "20.04",
"name": "ubuntu"
},
"channel": "candidate"
},
And for mysql:
{
"error-list": [],
"results": [
{
"charm": {
"id": "F8CtvgcznoeRSupRrY2uEa67oQtBTF7x",
"license": "",
"name": "mysql",
"publisher": {
"display-name": "Data Platform",
"id": "gVVkuxw4C56POG1eszt4RPR3L5Eak8XE",
"username": "data-platform",
"validation": "unproven"
},
"summary": "Charmed MySQL VM operator",
"type": "charm"
},
"error": {
"code": "revision-not-found",
"extra": {
"releases": [
{
"base": {
"architecture": "amd64",
"channel": "22.04",
"name": "ubuntu"
},
"channel": "8.0/stable"
},
{
"base": {
"architecture": "amd64",
"channel": "22.04",
"name": "ubuntu"
},
"channel": "8.0/candidate"
},
In both cases the resulting list is congruent and has the same structure. What I think might be happening is that Juju is confused by the fact that for mysql, the first item has a “track” component in the channel, whereas perhaps Juju was expecting a “naked” risk, and that’s why it doesn’t choose it.
If you specify a base, then the request Juju makes does have a concrete base, it’s instead:
curl -XPOST -s https://api.charmhub.io/v2/charms/refresh -H 'Content-type: application/json' -d '{ "context": [], "actions": [{"name": "mysql", "base": {"name": "ubuntu", "channel": "22.04", "architecture": "amd64"} , "channel": "stable" , "action": "install", "instance-key": "a-test"}]}' | jq .
You’ll notice in this case charmhub does give a concrete revision since, given a base and a channel, we usually can always resolve that to the specific revision to be installed.
At this point I would advocate some exploration on the Juju side to understand why it’s getting confused by the default track on a charm that has no latest track.
- Daniel
@roadmr, When juju sends a base of {"architecture":"amd64","name":"NA","channel":"NA"}, it
is expecting the “invalid-charm-base” error with a list of “default-bases” as part of the error response in the case where there are valid charms in the channel provided. For some reason the mysql charm is returning “revision-not-found” which juju interprets as not available charms in the channel, here are all of the other channels available.
You can see the error responses juju expects deploying the ubuntu charm. Influxdb is also deploying successfully doing the base negotiation dance.
The actual call juju makes to request a list of bases to try in the channel is:
curl -XPOST -s https://api.charmhub.io/v2/charms/refresh -H 'Content-type: application/json' -d '{"context":[],"actions":[{"action":"install","instance-key":"ba0ea644-b34a-4a8c-83eb-4f3930ac8e83","name":"mysql","channel":"stable","base":{"architecture":"amd64","name":"NA","channel":"NA"}}],"fields":["bases","config-yaml","download","id","license","metadata-yaml","name","publisher","resources","revision","summary","type","version"]}
The base in the provided example is not what juju sends. You can compare the response from above with asking for the influxdb charm or even ubuntu.
Interestingly, if you deploy mysql with a series defined, we get a response including the effective channel of “8.0/stable” and deploy the charm successfully.
1 Like
@hmlanigan awesome, thanks - that makes the difference super clear. It’s likely our dodgy code that returns invalid-charm-base is confused by the absence of the latest track, it’s not default track-aware.
I’ll file a bug on our side to get this looked at.
- Daniel