Snap Store Server

Juju cannot deploy charm revision from closed track: unable to fetch OCI image resources

Bug #2020753 reported by Alex Lutay
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical Juju
Triaged
Medium
Unassigned
Snap Store Server
New
Undecided
Unassigned

Bug Description

Hi,

It is a bugreport branched from the MM question:
> https://chat.charmhub.io/charmhub/pl/3huptnewqjyg3ghgcnx5eydgjh

---
The charmhub track can be closed, but the last revision there is still installable,
e.g. mysql-k8s or mysql-router-k8s in the latest/edge.
It looks like resources are no longer reachable for the closed tracks/revisions:

ubuntu@taurus-dev:~$ juju deploy mysql-router-k8s --channel latest/edge --trust
Located charm "mysql-router-k8s" in charm-hub, revision 24
Deploying "mysql-router-k8s" from charm-hub charm "mysql-router-k8s", revision 24 in channel latest/edge on jammy

ubuntu@taurus-dev:~$ juju debug-log --tail
...
controller-0: 13:24:27 ERROR juju.worker.caasapplicationprovisioner.runner exited "mysql-router-k8s": getting OCI image resources: unable to fetch OCI image resources for mysql-router-k8s: while getting resource from charmhub: resource "mysql-router-image" not found
---

Sergio reply: "... it seems strange that you can install anything from a channel that is closed ..."

The discussion on Engineering meeting went to no final decision, bugreported here:

Juju either have to:
1) do NOT allow to install revisions from closed tracks (e.g. snap way of closing tracks)
2) allow to install revision from closed tracks => fix resources availability (e.g. OCI for K8s charms).

Thank you!

---

P.S Keep in mind, it is NOT possible to install charm by revision too (using closed channel), but possible for the same revision using open channel:

```
juju deploy mysql-router-k8s --revision 24 --trust --channel latest/edge # fail
juju deploy mysql-router-k8s --revision 24 --trust --channel 8.0/edge # works
```

Which means: resources are still available in sore, but juju do not see them if channel is closed.

P.P.S see also charmcraft discussion here: https://github.com/canonical/charmcraft/issues/1108

See original description
Tags: charmhub
Alex Lutay (taurus)
description: updated
description: updated
Alex Lutay (taurus)
description: updated
description: updated
Revision history for this message
Alex Lutay (taurus) wrote :

The similar discussion in snapstore: https://bugs.launchpad.net/snapstore-server/+bug/2020681

Revision history for this message
Joseph Phillips (manadart) wrote :

I think we should disallow *new* deployments from closed tracks.

But we don't want to strand someone who has such a revision deployed, with regard to scaling concerns.

Changed in juju:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

I just want to pedantic-clarify, that this rule should apply to closed channels; the track piece is a component to said channel.

Revision history for this message
John A Meinel (jameinel) wrote :

just like you can deploy a charm by revision, you can also deploy resources by revision. (IIRC, juju deploy mysql-router-k8s --revision 24 --resource mysql-router-image=10
note that I don't know what revisions of the mysql-router-image are available)

There are existing issues against charmhub that it doesn't match a given charm revision with its resources (if you try to deploy revision 20 of the charm but target the channel 8.0/edge it will grab the latest resources from 8.0/edge and not the resources that 'came with' the charm when it was at revision 20).

AFAIK, there is no way to disable a revision that has been exposed publicly in the past. (if you pushed a revision 10 to the store, but never published it, then it won't be accessible, but if you have published 10, then someone can always ask for --revision 10 in the future.)

That would be more on the Store, than on Juju if we wanted to provide that sort of close-and-fully-remove.

As for Joe's comment, according to Alex we already do that:
```
 juju deploy mysql-router-k8s --revision 24 --trust --channel latest/edge # fail
```

The issue is that we support any revision that the store exposes, but the store doesn't align the resources with the revision. Either way I'm pretty sure this is still a snapstore server bug, not a bug in juju.

tags: added: charmhub
Revision history for this message
John A Meinel (jameinel) wrote :

It seems to be failing for the wrong reason, but it is refusing to deploy from a non-existent channel:
```
$ juju deploy mysql-router --channel nosuchchannel/stable --revision 24
ERROR listing resources for charm "ch:amd64/mysql-router-24": No revision was found in the Store.
ERROR failed to deploy charm "mysql-router"
```

And for a channel that exists but doesn't have any revisions:
```
$ juju deploy mysql-router --channel latest/stable --revision 24
ERROR listing resources for charm "ch:amd64/mysql-router-24": No revision was found in the Store.
ERROR failed to deploy charm "mysql-router"
```

And mysql-router itself doesn't even have resources (that I can find).

Revision history for this message
Alex Lutay (taurus) wrote :

Hi Jon, thank you for trying to trace this down.

TL;DR: is it not possible to deploy closed channels using Juju 3.1.6 today. Resolved?

re: > And mysql-router itself doesn't even have resources (that I can find)

The ticket is about K8s charms: "unable to fetch OCI image resources", but you were checking mysql-router VM.

Anyway, today, using Juju 3.1.6 I cannot reproduce the initial issue at all
(e.g. mysql-k8s latest/* are closed):

> > juju deploy mysql-k8s --channel latest/edge --trust
> ERROR selecting releases: charm or bundle not found for channel "latest/edge", platform "amd64"
> available releases are:
> channel "8.0/edge": available series are: jammy
> channel "8.0/stable": available series are: jammy
> channel "8.0/candidate": available series are: jammy
> channel "8.0/beta": available series are: jammy

I believe something has changed on Juju/Charmhub level.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.