[Wishlist] means within a charm to collect a list of running agents

[Xav Paice]

This is specific to machine charms only.

I have an application where I wish to tag machines based on the applications that run on the machine. For example, my subordinate may wish to tag a machine as "keystone" if it has the Keystone application running (cs:keystone), plus "keystone-hacluster" if it has that subordinate. I'd like a tag for each application, no need to filter, and the tag is OK to be the application name as provided by Juju.

Currently I would look at the content of /var/lib/juju/agents, and find all the directories with unit-*, pulling the names with a regular expression.

It would be helpful if there's a way to query machine information from a supported Juju command rather than use this pattern which doesn't appear to be the most portable, or secure, method.

[Harry Pidcock (hpidcock)]

This actually sounds like it could be a feature of juju, to expose machine specifics as tags on the cloud. Is this what you mean by tagging the machines? I could imagine this also being on k8s as well (as generated annotations/labels).

Could we understand your use case more?

[John A Meinel (jameinel)]

"Query machine information from a Juju command", are you saying from a human client (eg `juju machine-...`). Or are you saying from the charm itself? We have talked about updating Provider metadata (like MAAS or AWS tags), so that the provider dashboards have a nicer view (machine-XYZ getting a postgresql tag so you can see what unit/applications are running on which instances).
Is that sufficient for your functional case, or is there a specific tag that you are trying to apply?

Generally we don't really like charms knowing about applications they aren't related to, but if we could understand the use case a bit more it might be reasonable.

[Xav Paice (xavpaice)]

The particular use case is for updating machines in Landscape, to allow a list of applications hosted on each machine to be used to do things like "update all the packages on the Keystone units in AZ1", or operations like that.

For that, I'd want the landscape-client subordinate charm to be able to 'look' at the machine, and obtain a list of all the 'other' units on the machine (including units that are principal units or subordinates unrelated to the charm itself).

One example:

Machine 15 has two principal units:
nova-compute
ceph-osd

each of those has a variety of subordinate units for things like monitoring etc.

I'd like landscape-client, which is (e.g.) a subordinate of nova-compute, to know about the subordinates of ceph-osd, even though there's no relation at all. That's easy right now with a simple 'ls /var/lib/juju/agents' (for linux, at least), this is more a request to be able to get that list using a tool within the charm that is more operating system independent. In this example, that list (along with other environmental info like availability zone) gets sent to Landscape for adding tags.

[John A Meinel (jameinel)]

In the general case, I don't think we want charms to be behaving differently because they happened to be colocated with a particular other application. So for most cases we would rather they did not look at their environment.
However, there is an interesting case for things like landscape-client where it is really more about being a *machine* subordinate, where it wants to be monitoring everything going on in that machine (vs just the application that it happens to be related to, because we don't have a way to express charms that need to be present on a 'set of machines')
I think this would be more interesting for the DaemonSet/machine subordinate case than for the application subordinate case.

That said, looking at /var/lib/juju/agents doesn't feel that dirty, and the landscape-client charm doesn't run on non-linux, does it?

[Kevin Nasto (silverdrake11)]

The ability for Landscape client to report on juju agents by looking at the /var/lib/juju/agents file seems like a great idea for a feature request. Taking that information and adding/removing tags based on what juju agent is running seems a bit out of scope for the client and the charm.

The use case seems to be for Landscape to install different packages on the computer, depending on which juju agents are attached to it (implemented via tagging).

If we add this juju agent feature, then the best way is to read that from the api and add or remove tags (perhaps a separate script running on one machine that has access to the api). If something is needed now, than the best way is still to use the api for tagging, but it will be more complicated since the script will have to run on each individual machine

[Martin Kalcok (martin-kalcok)]

After a talk with Kevin and Mitch, it seems like this feature is currently not feasible. Landscape itself does not support deletion of tags via client config. This means that if application unit would be removed from the machine, landscape-client would not be able to remove the tag from the server in Landscape.

Alternative, as Kevin mentioned, is usage of admin API which has ability to both add and remove tags. However this would require the landscape-client units to have admin API key which is not a good thing.

The true alternative is making landscape itself more juju-aware but that's not currently in short term plans if I understand it correctly.