juju is allowing k8s charms to be deployed on machine clouds

Bug #1996906 reported by Niels Robin-Aubertin
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
Invalid
Undecided
Unassigned

Bug Description

I created a virtual maas cloud and naively tried to `juju deploy` the hello-kubecon charm on it using juju 2.9.37-ubuntu-amd64 (installed as a snap).
Instead of immediately failing, it allowed the operation to finish. `juju status` was informing me of "waiting for Pebble in workload container".
Tried on an lxd cloud by a coworker, it gave him another message: "waiting for machine".

Tags: canonical-is
Tom Haddon (mthaddon)
tags: added: canonical-is
Revision history for this message
Juan M. Tirado (tiradojm) wrote :

If a charm is specifically designed to be run on K8s, Juju expects the assume field to be populated with a `k8s-api` value. Otherwise, Juju will try to deploy the charm in a machine. I will set this as invalid as Juju is behaving as expected. This problem could be considered to be on the Charm design itself.

Changed in juju:
status: New → Invalid
Revision history for this message
Tom Haddon (mthaddon) wrote :

Are you sure about this? This would basically mean changing pretty much every k8s charm, and significant documentation updates. For example on https://juju.is/docs/sdk/metadata-yaml it says:

```
# (Optional) A map of containers to be created adjacent to the charm. This field
# is required when the charm is targeting Kubernetes, where each of the specified
# containers will be created as sidecars to the charm in the same pod.
containers:
```

This implies that having a "containers" entry is all that's needed for a kubernetes charm. What exactly will Juju do with the "containers" entry on a machine charm currently?

Revision history for this message
Simon Aronsson (0x12b) wrote :

> This would basically mean changing pretty much every k8s charm, and significant documentation updates.

We've done these changes to all of the observability charms a while ago, and I think the MLOps team went ahead and did the same.

Personally, I prefer the current way of the containers key being present not necessarily meaning that it's not deployable on machines. Why? In the future, I'm hoping we'll implement a way for container-based charms to be deployed on machines as well without necessarily requiring a Kubernetes cloud (think containerd and/or podman/docker on the machine, running only the charm)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.