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

Bug #1766666 reported by Drew Freiberger on 2018-04-24
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
Wishlist
Unassigned

Bug Description

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) wrote :

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.

Changed in juju:
importance: Undecided → Wishlist
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers