metallb charm has hard coded metallb image

[Jeff Hillman]

metallb latest/stable

There is no config option to change the upstream metallb image being pulled. it is instead hardcoded to both metallb/speaker:v0.12 and metallb/controller:v0.12

This means that in the current state, the charm is locked down to those versions. At the time of writing, latest version is 0.13.7

[George Kraft (cynerva)]

The images are charm resources which can be attached independently. You could try attaching the 0.13.7 images and see how it goes:

juju attach metallb-controller metallb-controller-image=quay.io/metallb/controller:v0.13.7
juju attach metallb-speaker metallb-speaker-image=quay.io/metallb/speaker:v0.13.7

Keep in mind that we haven't tested the charm with metallb 0.13.7 images, so we can't guarantee it will work correctly with them.

[George Kraft (cynerva)]

I think a config option would provide a more intuitive user experience here than the charm resources, but our ability to deliver config options will be heavily dictated by the future architecture of these charms. For context, right now they are "pod spec" charms which are largely unsupported in Juju these days.

For metallb-speaker: The workload is a DaemonSet, so it will likely become an imageless sidecar charm that creates a DaemonSet via k8s API. A config option for the image would make sense here.

For metallb-controller: The workload is a Deployment, so it will likely become a proper sidecar charm in which the charm is a sidecar to the metallb-controller image, managed by Juju. For this the image *has* to be a charm resource.

That would be pretty much the most confusing UX I can imagine for this - a config option on one charm, and a charm resource on another. But it's what the "obvious" architecture guides us toward. Perhaps we should consider some other architecture.

I will leave this issue option for consideration.

[Adam Dyess (addyess)]

Progress is being made towards resolving this issue in 1.28 release

* metallb can now be deployed using a single charm rather than two
* metallb is no longer a podspec charm meaning the hard-coded-ness of the version is now a bit more slippery
* metallb in the 1.28 charm will ship with the 0.13.10 release
* metallb now will have a configuration option to allow future charm builds to incorporate more versions within the charm.

Lets hope this helps