Support for tagging VMs and containers (and potentially other stuff...)

Incus
1

I have done some googling and didn’t find any mention of tags on VMs/containers being a thing. ChatGPT told me that groups could be an option but I can only find info on cluster groups.

What I have in mind is integrations to Incus from downstream systems that would use this metadata e.g. to perform actions - add to monitoring, enroll in a CMDB, etc - specifically to provide information such as the application system/software, the environment (Dev, Prod), etc.

edit: the ability to use key/value attributes (application: kafka, owner: integration, env: prod) against instances would be preferable to simple, static string tags.

2

I think metadata can be an option.

1 Like
3

Thank you @abiosoft. That looks like exactly what I was looking for.

incus config metadata edit hostname

Then set via the properties map. I knew there had to be something like this. :slight_smile:

edit: actually, looking a bit further, it appears that those properties might be limited in terms of what keys can be used. Perhaps there’s another area where arbitrary K/Vs can be set against instances?

4

I went ahead and tried it, and it allowed me to set an arbitrary property.

$ sudo incus config metadata show ddclient
architecture: x86_64
creation_date: 1764054241
expiry_date: 0
properties:
  myprop: myvalue
templates: {}

So next question will be - is this the correct/idiomatic way to handle this requirement?

5

And one further question would be how to apply these properties via Terraform. I tried as below but it doesn’t accept properties.

locals {
  instance_props = {
    ddclient = {
      myprop             = "myvalue"
    }
  }
}

...
[within `incus_instance` resource block]

  config = {
    "boot.autostart"   = true
    "limits.cpu"       = 1
    "security.nesting" = true
    "properties"       = jsonencode(local.instance_props["ddclient"])
  }

The plan looked good, but I got this error. So it’s probably my understanding of the data model that is not right. I haven’t had time to get familiar with the Incus API yet, but will work on it.

incus_instance.ddclient: Modifying... [name=ddclient]
╷
│ Error: Failed to update instance "ddclient"
│
│   with incus_instance.ddclient,
│   on ddclient.tf line 10, in resource "incus_instance" "ddclient":
│   10: resource "incus_instance" "ddclient" {
│
│ Invalid config: Unknown configuration key: properties
╵
6

Maybe setting the properties is yet to be implemented in the terraform provider.

7

Don’t you just want to set user.XYZ config keys?

incus config set MY-INSTANCE user.application=kafka user.owner=integration, user.env=prod

You can then easily use those for filtering, for example:

incus list user.env=prod
2 Likes
8

Thanks @stgraber. Yes, that looks like it’ll do the job.

So in the incus_instance resource in Terraform, we ended up with this:

  config = {
    "boot.autostart"   = true
    "limits.cpu"       = 1
    "security.nesting" = true
    "user.app"         = "ddclient"
    "user.env"         = "prod"
  }

I am then able to list instances via those user.* config keys and their values, or retrieve the value for a single VM as below:

$ sudo incus config get ddclient user.env
prod
9

Yep, that’s the way to go. We support user.XYZ basically on everything that has a config key, not just instances.

1 Like
10

Am I correct in understanding that the only way to view these user.* config keys in the Incus web UI would be by switching to the YAML configuration view for an instance?

11

Yeah, you can filter with them using user.foo=bar in the instance search, but they don’t appear anywhere other than in YAML.

Feel free to file an issue at GitHub - zabbly/incus-ui-canonical: Fork of canonical/lxd-ui for use with Incus (gets rebased frequently) as making them more visible would make a lot of sense, at least on instances.

I think we probably would want them showing up on the instance page as User properties and then similarly in the configuration so they can be seen and set without having to use the YAML view.

@presztak ^

1 Like
12

Thanks again @stgraber. That would be fantastic if we could expose this very useful context to administrators using the UI.

I think having a dedicated section for these config entries as you propose would also help with discoverability for the tagging/metadata side.

13

I’ve logged this: