Cannot find newly released operator charm in search

We checked and the reason for this is that newly-registered charms are marked as "unlisted" so they don't appear in find results.

Unlisted should not show in find but should show in info and refresh and thus deploy should work.

Hmmmm ... `juju info microk8s-testbed` works. But juju deploy doesn't.

@simonrichardson are we relying on the find command for part of the deploy process?

We're not relying on find at all other than in `juju find`.

I'll investigate why it's failing to find it with refresh.

Two things:

 - Firstly it's only ever returning s390x[1] architecture (not sure if that's intended?)
 - Secondly the refresh API is returning id-not-found even though we're supplying the correct one[2]

Seems like an issue with the charmhub API.

1. https://paste.ubuntu.com/p/nrYvZypSrB/
2. machine-0: 09:29:05 CRITICAL juju.apiserver.charms Locate charm using: Refresh one (instanceKey: 67cf7ef4-37bf-401e-853d-5ea34dec28b6): using ID NKescbK9jZs3Zvs1AsIU96lRPz666BN5 revision 2, with channel latest/stable and platform s390x/ubuntu/focal

Oh so this seems to be two bugs in one.

Info is returning s390x because:

if platform is not given, we ignore the arch (ie.platform), and then when sorting entries it seems the "most stable" is s390x (for snaps we fix this to amd64 when there is no arch in the request).

(when we only have all, this is not an issue).

we may need to do something similar here for charms, I guess. ie, choose a default platform when we don't have one.

ALso interestingly the info endpoint for charms does not support sending the platform (which would be the right solution), though it does for snaps.

So maybe we can do both: allow and honor platform specification in info, and set amd64 as the default when there's no given platform (although does that assumption make sense with juju? for snaps it does as amd64 is the most popular arch by far).

One other thing: could you perhaps show the exact payload/request you're sending to refresh to check whether it's the same platform issue or maybe a third different problem?

Thanks!

> I guess. ie, choose a default platform when we don't have one.

This should always be amd64.

> One other thing: could you perhaps show the exact payload/request you're sending to refresh to check whether it's the same platform issue or maybe a third different problem?

I dug this out from the logs, which is to say:

machine-0: 09:29:05 DEBUG juju.apiserver.charms Locate charm using: Refresh one (instanceKey: 67cf7ef4-37bf-401e-853d-5ea34dec28b6): using ID NKescbK9jZs3Zvs1AsIU96lRPz666BN5 revision 2, with channel latest/stable and platform s390x/ubuntu/focal

As of today, after uploading an addition revision, this works on staging.

It looks like juju info is still passing back misleading arch information, however.