Juju gives us the ability to deploy apps indistinctly on bare metal (or VM) or inside a LXD container.
LXD containers are great and the best way to deploy apps but there are some charms that must not be deployed in containers for obvious reasons, usually, direct access to low level layers such as storage devices, NICs, …
This is the case for ovn, ceph-osd, … but there is nothing to that can block you from doing this and sometime, the choice between bare or LXD is not that obvious.
Would be great to have a way to know if a charm can’t be installed in a LXD containers, either by throwing an explicit error in juju status and/or having a visible attribute in the Charm description for example.
The NTP charm checks for that and disables time syncing when running as a container (ntp.py\reactive - ntp-charm - [no description]), but this is done at run-time, Juju is not aware of that.
Why not but simply, at least, something visually explicit somewhere on the charmhub page, like a tag or something so that you just know this charm is supposed to be used as a subordinate and this one, is supposed to run on bare OS only and not in LXD.
This would be a minimum to me, would be best iof this could be used as a constraint in the charm itself so that, if, for example, you deploy a “bare only” charm to a LXD containers, it triggers an explicit error saying “this charm can’t be used inside a container” … something like that but you get the idea.
Yes, this sounds like a good use case. I think we intend to have an “assumes” mechanism that lets a charm author tell Juju when a charm can be expected to work, which could also handle this use case.
