Cannot find newly released operator charm in search

Bug #1908427 reported by Pete Vander Giessen on 2020-12-16
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snap Store Server
Undecided
Unassigned

Bug Description

I recently used charmcraft to publish a charm called microk8s-testbed. It looks like it got successfully published to the staging server:

https://charmhub-io-700.demos.haus/microk8s-testbed

However, the charm doesn't show up in search results:

https://charmhub-io-700.demos.haus/?q=microk8s-testbed

juju find and juju deploy don't work for the charm, probably because of the issue w/ it not showing up in search.

Daniel Manrique (roadmr) wrote :

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

Changed in snapstore-server:
status: New → Confirmed
Bret Barker (noise) wrote :

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

Pete Vander Giessen (petevg) wrote :

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

Daniel Manrique (roadmr) wrote :

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

Pete Vander Giessen (petevg) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers