new series in edge channel of k8s charm not visible
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Triaged
|
Medium
|
Unassigned |
Bug Description
We're recently updated the nginx-ingress-
My expectation would be that the series used to run a charm would be transparent to the user - they would simply issue a `juju refresh` command and get whatever the latest published version of the charm in the series they're tracking is. This a k8s charm where you can only have one series at a time.
However, it seems you need to specify the series to get the relevant revision of the charm.
```
mthaddon@
name: nginx-ingress-
publisher: Tom Haddon
summary: |
An operator to configure a kubernetes ingress.
description: |
An operator to configure a kubernetes ingress.
store-url: https:/
charm-id: aQVXlrbsLWBTiAi
supports: focal
subordinate: false
relations:
provides:
ingress: ingress
requires: {}
channels: |
latest/stable: 40 2022-11-10 (40) 8MB
latest/candidate: ↑
latest/beta: ↑
latest/edge: 42 2022-11-14 (42) 12MB
mthaddon@
name: nginx-ingress-
publisher: Tom Haddon
summary: |
An operator to configure a kubernetes ingress.
description: |
An operator to configure a kubernetes ingress.
store-url: https:/
charm-id: aQVXlrbsLWBTiAi
supports: focal
subordinate: false
relations:
provides:
ingress: ingress
requires: {}
channels: |
latest/stable: 40 2022-11-10 (40) 8MB
latest/candidate: ↑
latest/beta: ↑
latest/edge: 40 2022-11-10 (40) 8MB
```
Based on the above, if I do a `juju deploy nginx-ingress-
Similarly for charm upgrades, I'd expect that you can just do `juju refresh nginx-ingress-
To me one of the big advantages (I had thought) of k8s charms was that there was only one series of your charm, and that charm authors could choose what that series would be and charm users would consume whatever the published series for a charm was. This would mean charm users don't have to deal with the complexity of series upgrades, which they do have to deal with in the machine charm world.
tags: | added: canonical-is |
Changed in juju: | |
milestone: | none → 2.9-backlog |
status: | New → Triaged |
Changed in juju: | |
milestone: | 2.9-backlog → none |
We'll need to consider how to move forward with this.
K8s charms *do* have a series, and the current designs do intend to keep that.
Machine charms certainly have a model where 'juju refresh' stays within a series/base boundary.
It would be reasonable to loosen that for K8s charms, though we'll need some discussion in that space around "universal" charms (where you can deploy a charm and not care whether it is going to bare metal, or to a K8s environment).
As for the 'not finding jammy' when specifying "edge" that is a different charmhub bug. Specifically, the default base selection for charmhub only looks at bases that have been released to "stable" even when specifying "edge".
So Juju says "give me something on edge, but I don't know what base", which Charmhub replies with "possible bases are: 20.04", and then juju comes back and says "give me something on edge from base 20.04".
We have a separate bug tracking the ability for charmhub to give a different base selection based on the channel of the charm that we are requesting. (bug #1981579)