Better error message when charm cannot be found

[Leon]

Seems like juju (3.1.6) is having trouble deploying a charm from a temporary branch (edge/325).

Tried to deploy a bundle + overlay:

juju deploy --channel=edge cos-lite --trust --overlay /home/ubuntu/overlay-load-test.yaml --trust

This errored out:

ERROR cannot deploy bundle: cannot resolve charm or bundle "loki-k8s": selecting releases: ambiguous arch and series with channel "edge/325", specify both arch and series along with channel

The offensive section looks like this:

--- # overlay.yaml
applications:
  loki:
    channel: edge/325
    options:
      ingestion-rate-mb: 60
      ingestion-burst-size-mb: 100
    resources:
      loki-image: ubuntu/loki:2.8.4-22.04

Seems odd that juju (3.1.6) requires arch and series when there is one and only combo available on charmhub.

Appendix 1
==========

After adding

    arch: amd64
    series: jammy

now it errors out with:

ERROR cannot deploy bundle: cannot resolve charm or bundle "loki-k8s": no releases found for channel "edge/325"

Appendix 2
==========

After changing to

    channel: latest/edge/325
    arch: amd64
    series: jammy

it errors out with

ERROR cannot deploy bundle: cannot resolve charm or bundle "loki-k8s": no releases found for channel "latest/edge/325"

[Ian Booth (wallyworld)]

The issue is that the loki-k8s charm in edge/325 only supports 20.04 (focal). There's no jammy support.

This overlay works

applications:
  loki:
    channel: edge/325
    arch: amd64
    base: ubuntu@20.04
    options:
    ingestion-rate-mb: 60
    ingestion-burst-size-mb: 100
    resources:
      loki-image: ubuntu/loki:2.8.4-22.04

The error message could be better. The response from charmhub does include the supported bases so that should be surfaced to let the user know how to correct the problem.

[Leon (sed-i)]

Thanks Ian! Didn't notice that indeed.

And about the 'ambiguous arch and series with channel "edge/325"' error - since there is only one option, could juju automatically try to pick it?

[Ian Booth (wallyworld)]

If there were no other series/base and/or arch constraints in place that would otherwise exclude that sole charm, then you'd expect Juju could pick that one all other things being equal.

Note that there's a model config item called "default-base" which can be set, and if that's not set, Juju falls back to 22.04 as being the base to use if not specified. So that's why I think Juju did not select that 20.04 charm. That's why you need to include base in the bundle.

So I think it still comes back to the error message being a bit rubbish.

[John A Meinel (jameinel)]

So with:
juju model-config -m controller logging-config="<root>=INFO;#charmhub=TRACE"

I was able to get debug-log to spit out what queries it is doing against charmhub.
To start with, it is very poor that `juju info loki-k8s --channel edge/325` is unable to give any responses about the charm.

We start by trying to resolve what loki-k8s in channel 'edge/325' is. (note that we do supply an architecture, as Juju has a default architecture, but shouldn't have a default base):

machine-0: 17:56:47 TRACE juju.apiserver.charms.charmhubrepo.client charmhub Refresh(charmhub.executeOne{
    ID: "",
    Name: "loki-k8s",
    Revision: (*int)(nil),
    Channel: &"edge/325",
    Base: charmhub.RefreshBase{Architecture:"amd64", Name:"", Channel:""},
    action: "install",
    instanceKey: "bf312794-0e9f-4a32-85d7-ed858b3c0425",
    fields: {"bases", "config-yaml", "download", "id", "license", "metadata-yaml", "name", "publisher", "resources", "revision", "summary", "type", "version"},
})

Unfortunately the response that comes back (which is meant to help us select the base), doesn't actually include the channel that we requested:
{
  "error-list": [],
  "results": [
    {
      "charm": null,
      "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" },
            { "base": { "architecture": "amd64", "channel": "20.04", "name": "ubuntu" }, "channel": "beta" },
            { "base": { "architecture": "amd64", "channel": "20.04", "name": "ubuntu" }, "channel": "edge" },
            { "base": { "architecture": "amd64", "channel": "20.04", "name": "ubuntu" }, "channel": "1.0/stable" },
            { "base": { "architecture": "amd64", "channel": "20.04", "name": "ubuntu" }, "channel": "1.0/candidate" },
            { "base": { "architecture": "amd64", "channel": "20.04", "name": "ubuntu" }, "channel": "1.0/beta" },
            { "base": { "architecture": "amd64", "channel": "20.04", "name": "ubuntu" }, "channel": "1.0/edge" }
          ]
        },
        "message": "No revision was found in the Store."
      },
      "id": "VpRGTlLZZh1ON756aodclPgvrXBZHrCN",
      "instance-key": "bf312794-0e9f-4a32-85d7-ed858b3c0425",
      "name": "loki-k8s",
      "released-at": null,
      "result": "error"
    }
  ]
}

At a minimum, we should understand the error response a little bit better. It isn't that there is an ambiguous architecture (one is supplied, and only that is returned), it is that the channel only returns 20.04 as available, but none of the channels that are returned are the one that was requested.

I get the same error if I specify "--channel latest/edge/325".

Now, to start with, the fact that we asked charmhub "I need to know what `loki-k8s` channel=`edge/325`" means, and it doesn't come back with a response that includes the channel that we asked for is certainly a problem.

If you do specify a base, so that the automatic lookup doesn't need to happ...

[John A Meinel (jameinel)]

I'm including snapstore-server here, because there is meant to be a base automatic-detection. But when we send a request and they respond with 'no such revision', they aren't including the channel that we requested.

You can see that our initial REFRESH request does include a channel:
machine-0: 17:56:47 TRACE juju.apiserver.charms.charmhubrepo.client charmhub Refresh(charmhub.executeOne{
    ID: "",
    Name: "loki-k8s",
    Revision: (*int)(nil),
    Channel: &"edge/325",
    Base: charmhub.RefreshBase{Architecture:"amd64", Name:"", Channel:""},
    action: "install",
    instanceKey: "bf312794-0e9f-4a32-85d7-ed858b3c0425",
    fields: {"bases", "config-yaml", "download", "id", "license", "metadata-yaml", "name", "publisher", "resources", "revision", "summary", "type", "version"},
})

But the response doesn't filter to the channels that we have requested, but gives the generic "here are the public bases that are available". Which isn't useful for a lot of reasons. I believe the issue is the juju client realizes that it isn't filtered, and thus filters the response to only include what we requested, and thus cannot see a base for a channel.
(Imagine that the 'edge' channel only supports 22.04, but 'stable' only supports 20.04, Juju wants to supply the channel to charmhub if we know it, and have charmhub say 'if you are selecting edge, default to 22.04, but if you supply 'stable' then select 20.04)

I do think Juju can try to do better with the error message. But the fundamentals are that charmhub is not respecting the channel that we supplied, and thus juju can't figure out how to proceed.

[John A Meinel (jameinel)]

It isn't that Juju is defaulting to Jammy but there is no jammy. The issue is that we are asking to resolve a base and Charmhub isn't returning anything usable.

And I *don't* think the answer is we asked about "channel=latest/edge" and while that wasn't in the response it happens that all of the other answers have the same value for base. That also won't result in correct behavior. (It may be a guess that is right more often than not, but if I am creating a testing channel expressly for the purpose of testing an alternative base, then it is definitely the *wrong* answer to match the bases from other channels.)