Feature Request: Ability to relate suboordinate charms to all machines (minus containers)

[Drew Freiberger]

When building cloud environments, we often have many subordinate charms that need to be related to all of the applications installed to the metals, however, there are sometimes smooshed applications that land two to a metal server, such as nova-compute and ceph-osd.

I'd like to propose a "magic" juju-info/container-scoped relation to all non-container machine units. The purpose of this would be to relate charms like canonical-livepatch, ntp, metal-specific nrpe units (for checking swap, disk, load). Often times we end up relating these charms to more than one unit that lands on a machine/vm and conflicts with another, such as relating nrpe to both nova-compute and ceph-osd to ensure both charms are able to land their nrpe-external-master configs on the filesystem for nagios service-specific monitoring. The two charms then have conflicts living together on the same host.

We also need to ensure that all machines have livepatch installed for security compliance, however, there is no good utility to list out which metals/vms in a model are and are not covered by a given subordinate charm as the installed machine number is not listed in juju status output for suboordinate charms w/out chasing upstream to the charm it is subordinate to.

[John A Meinel (jameinel)]

I'm curious about syntax for this, and if it is always true that you want machines and not containers. We have talked about having machine subordinates. Or possibly model subordinates. Figuring out the syntax is still something we'd need to go through.

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.