Add meta field to lima.yaml for user annotations #4103
Conversation
This field will not be used by Lima itself; users can add whatever objects they want. Possible uses are: * adding labels that can be used as selectors (see also lima-vm#3240) limactl edit mysql --set '.meta.database = true' limactl list --yq 'select(.config.meta.database).name' * adding anything that would normally be just a comment, like a description or keywords Signed-off-by: Jan Dubois <[email protected]>
| TimeZone *string `yaml:"timezone,omitempty" json:"timezone,omitempty" jsonschema:"nullable"` | ||
| NestedVirtualization *bool `yaml:"nestedVirtualization,omitempty" json:"nestedVirtualization,omitempty" jsonschema:"nullable"` | ||
| User User `yaml:"user,omitempty" json:"user,omitempty"` | ||
| Meta map[string]any `yaml:"meta,omitempty" json:"meta,omitempty" jsonschema:"nullable"` |
There was a problem hiding this comment.
FillDefault needs to be updated for overriding
There was a problem hiding this comment.
Bikeshedding: why not call this "labels"
There was a problem hiding this comment.
Bikeshedding: why not call this "labels"
-
Because I think of the value of labels as just strings (
map[string]string), not objects, and I don't want to put any constraints on the data a user wants to put there. -
I find
metamore generic thanlabels, e.g.meta.keywordslooks better to me thanlabels.keywords. And with point (1),meta.keywordscan be a[]string, butlabels.keywordswould be a comma-separated list that would need to be parsed and could not be used easily withjq/yq.
There was a problem hiding this comment.
FillDefaultneeds to be updated for overriding
I guess. And then it also should be supported by template embedding, for consistency.
At first I thought since Lima doesn't use the value of Meta, just declaring the field to make sure we don't get strict YAML errors would be enough. But I guess I was wrong. 😄
This field will not be used by Lima itself; users can add whatever objects they want.
Possible uses are:
adding labels that can be used as selectors (see also Feature suggestion: labels for VMs and disks (and networks) #3240)
adding anything that would normally be just a comment, like a description or keywords
This makes it possible to query and manipulate the data with applications instead of being solely for human consumption (see also Third-party template discovery #4097 (comment)).
I first called the field
metadata, but it just feels too long, especially since in filter expressions it becomes.config.metadata.It is unfortunate that most of the interesting data for filtering in the
listcommand is inside the.configobject, making all expressions longer and harder to read. The.nameand.statusproperties are about the only things outside of.configthat I regularly use.