analogue for the `k8s-api` assumes

[Robert Gildein]

I think there could bu alternative for `k8s-api` assumption.

It is possible to deploy a machine charm on k8s even if it doesn't
work and therefore I think it would be beneficial to have
an alternative to `k8s-api`.

A good example is rabbitmq-server, which you cloud deploy on
microk8s, but it does not work. It's not obvious from logs [1] why
it doesn't work, which leads to confusion.

---
[1]: https://pastebin.ubuntu.com/p/PzjhWBCgst/

[Grégory Schiano (gschiano)]

Hello,

I faced the exact same issue with influxdb. I deployed it on a controller in Kubernetes, and no error, no warning. The charm was failing at the install event.

That's very confusing and I didn't expect to be allowed to deploy a machine charm on a K8S controller

[Ian Booth (wallyworld)]

This issue is, what's a "machine charm". A so called machine charm could run perfectly well in a container in a k8s pod. It's not something juju can reasonably guess. Adding an extra assume keyword sounds like a reasonable request to stop deployment of charms known to only work on vms.

[Tom Haddon (mthaddon)]

I saw another occurrence of someone mistakenly deploying a machine charm on a k8s substrate this week. Each time it takes a while for someone to realise what the problem is, as the issue isn't immediately obvious.

[Tom Haddon (mthaddon)]

In terms of the question of 'what's a "machine charm"' this is something that charmhub already seems to have an answer to, based on what it's displaying in the "Platform" section of a charm.

[Tom Haddon (mthaddon)]

One thing to mention here is that some "machine" charms (according to charmhub) such as s3-integrator (https://charmhub.io/s3-integrator) do apparently work fine on k8s. I asked about this charm's usage on k8s specifically and was told some members of the Data Platform team are already deploying this charm on k8s. So any change that's made might have an impact on how some users are deploying charms.

[Alex Lutay (taurus)]

For the history, one more time K8s charm deployed on LXD with confusing error:

> unit-mongodb-k8s-2: 10:55:03 ERROR juju.worker.uniter.operation hook "db-storage-attached" (via hook dispatching script: dispatch) failed: exit status 1

We need ability to hint users about incompatibility situation clearly.

Extra findings: the charm can work well on MicroK8s/GKE/... but can be temporary broken for Amazon EKS.
Would be great to release "revision" with a precise lock, e.g.:

> mysql-k8s-operator.git/metadata.yaml
>> assumes:
>> - k8s-api
>> - not EKS:
>> message: "Amazon EKS is temporary NOT supported by this revision:"
>> url: https://bugs.launchpad.net/juju/+bug/1990279
>> - not VM:
>> message: "It is K8s operator, consider to use VM operator for your needs:"
>> url: https://charmhub.io/mysql

The list of keywords can be easily brewed: K8s(MicrkoK8s, GKE, EKS, ...), VM(LXD, OpenStack), ...

Tnx!