Nominate a Kubernetes charm with equivalent functionality as a "sibling charm"

One problem that we have with Kubernetes charms is that they are, well, different. Kubernetes requires same service to be packaged in multiple charms, because of its different operating environment.

As a community, we’ve developed a practice of using the -k8s suffix to charm names. That’s a pragmatic move, but I wonder if it’s a slightly brittle one. To my eyes, we’re pushing implementation details to the surface.

I wonder if we could use some functionality (within the charm store and/or the juju deploy command) for a classic charm to nominate a “Kubernetes sibling”.

Let’s say I run juju deploy mariadb inside a Kubernetes model. Juju asks the charmstore, “I know that mariadb only supports series x, y , z… has the charm author nominated a Kubernetes equivalent?” “Yes, okay great - I’ll deploy that one”.

This idea would reduce any transition costs for Juju users. It also allow charmers to use whatever charm naming convention that they prefer.

1 Like

There’s currently some design and specs going into how to cross the different architecture boundaries in the move to using the snap store as the single store for charms as well (both traditional and k8s) and namespacing cleanly is one of the goals with that.

I don’t have firm commitments on how that’s going to work at this time, but it’s definitely on our mind and in the specification todo items.

1 Like