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.