Two Telegraf charms on one machine fails install hook!

[Sebastien]

I deployed two charms on the same machine and wanted to add Telegraf to both the charms. The second charms always fails to open_port (line 196) since that port is already opened on that machine. The quick workaround I found was first closing the port since that will not give an error even if the port is already closed. Otherwise there should be a check if the port is already opened but I haven't found anything useful in the charmhelpers at the moment.

[Stuart Bishop (stub)]

I'm pretty sure this is WONTFIX. Even if Juju allowed one unit on the machine to break isolation and use resorces grabbed by another unit (the port), you can still only have one telegraf daemon listening on the port. There will also be clashes with the two charms (each unaware of the other) clobbering the other's configuration files.

While it is possible to smoosh multiple charms onto a single machine, it has never been recommended for this sort of reason. In some cases it was necessary, but the charms to separate lxd containers on the machine is a better and more reliable approach.

[Gregory Van Seghbroeck (gvseghbr)]

I'm not 100% convinced this behavior is not recommended by Juju. E.g. the HBase charms need to be deployed on the same machines as the Hadoop Datanodes.

If multiple Telegraf processes on a single machine are not the wanted behavior, I guess the charm should check whether there is already another Telegraf process running and if so, update the configuration file of the already running process.
If multiple processes can run on the same machine, the charm should make sure both processes actually can run, i.e. start on different ports, have multiple config files, etc.

[James Hebden (ec0)]

I'd be interested in some background on why this could be useful in the context of Telegraf.

The subordinate charm interface is geared towards placing and installing Telegraf on a host, the configuration of additional plugins that may be needed to monitor additionally installed software is the controlled through charm configuration, rather than relations. This includes loading any additional modules or input/output configuration you might need. If the additional telegraf unit is intended to make telegraf aware of our sensitive to some other software on the same system, the subordinate relation wouldn't be the way to go for that - we'd want to look at implementing additional interfaces to configure specific input plugins potentially.

[Christian Reis (kiko)]

This is kind of a perfect case for the "machine subordinates" concept that has been mooted a few times. In the case of this bug, it means we'd have a machine subordinate for Telegraf and services on that machine -- Hadoop & Hbase, for instance, registered with it.