Add meta for Nomad Variables

[prabirshrestha]

Currently nomad variables only supports key value pair. I would like it to attach extra meta properties to nomad variables.

My primary uses case is to allow gitops for nomad vars, ie. sync my git state for nomad vars with an actual nomad cluster. To do so I need to know if a nomad var was synced with my git sync tool or was manually added.

This can also be used to add other information such as description, examples, owner, doc links and so on.

[tgross]

Hi @prabirshrestha! So the idea here is that you'd like to have a separate "meta" block for semi-structured metadata? Changing the variable spec from (HCL example):

path      = "path/to/variable"
namespace = "default"

items {
  key1 = "value 1"
  key2 = "value 2"
}

to

path      = "path/to/variable"
namespace = "default"

items {
  key1 = "value 1"
  key2 = "value 2"
}

meta {
  meta_key1 = "meta value 1"
  meta_key2 = "meta value 2"
}

If I remember some of the design discussions I had with @angrycub over Variables, this was something we originally considered but deferred as a "maybe some day". The contents of the meta block would still be made available to jobs (unless we changed the definition of ACL capabilities in a backwards-incompatible way). So it's possible to workaround this today by adding the metadata to the items block.

If we were to implement this, there's a few details to work out:

• Are the contents of the meta block encrypted like the items block is?
  • If so, can we encrypt them together in a single blob?
  • If not, are the contents of the meta block available in the List Variables API?
• The contents of the meta block will need to count against size quotas.

[prabirshrestha]

Here is the tool that I'm looking to add gitops support for nomad vars.

Currently we use meta for jobs so only jobs that have been created by the tool will be deleted if it no longer exists in git repo. This allows slow migration and won't accidently delete nomad jobs.

https://github.com/jonasvinther/nomad-gitops-operator/blob/41b1216f06ffa543e6aeb2054f95ec2269752c78/pkg/nomad/nomad.go#L73C1-L76C23

// Adding metadata to identify the jobs managed by the Nomoporator
metadata := make(map[string]string)
metadata["nomoporater"] = "true"
metadata["uid"] = "nomoporator"
job.SetMeta(metadata)

I would like to do the same for variables. What you are proposed is exactly what I'm looking for.

Since meta was not supported, I had actually thoughts of adding a special known variables with list of keys. The only reason I see it may not work is when one adds loops they would need to filter the key out.

items {
  key1 = "value 1"
  key2 = "value 2"
  nomoporater_managed_keys = "key1,key2"
}

I don't see me requiring encryption for meta, but I'm ok if it is encrypted as long as I can decrypt it when I fetch using the api in my tool.

I expect to use very few variables. Its primarily for my homelab, so the only things I will put is most likely domain and few secrets used by the jobs. At somepoint I may even migrate to using vault of secrets, but want to have minimal maintenance for my homelab hence one of the major reasons of choosing nomad over k8s.

[tgross]

Thanks for that extra context on your use case @prabirshrestha.

Currently we use meta for jobs so only jobs that have been created by the tool will be deleted if it no longer exists in git repo. This allows slow migration and won't accidently delete nomad jobs.

Clever!

I don't see me requiring encryption for meta, but I'm ok if it is encrypted as long as I can decrypt it when I fetch using the api in my tool.

Yeah that makes sense. Right now the Variables ACL capability has a separate read and list capability. With list, you can call the List Variables API and the response doesn't include the encrypted Items field, just the metadata (like path, namespace, index, etc.). Whereas read gives you access to the encrypted Items field. I could see going either way with the Meta block, and the name certainly matches the data available in the list capability.