CLI: Rework cmpInstanceKeys for contextual completions based on instance type

[kadinsayani]

Fixes #14689.

Summary of changes:

• Adds completions for cloud-init.* config keys.
• (WIP) Correctly provides completions based on instance type.

[tomponline]

this looks fishy, whats it comparing to?

[kadinsayani]

The condition field for a cloud-init.* instance config key:

			"cloud-init": {
				"keys": [
					{
						"cloud-init.network-config": {
							"condition": "If supported by image",
							"defaultdesc": "`DHCP on eth0`",
							"liveupdate": "no",
							"longdesc": "The content is used as seed value for `cloud-init`.",
							"shortdesc": "Network configuration for `cloud-init`",
							"type": "string"
						}
					},

Alternatively, we could add all keys under the cloud-init map.

[tomponline]

why are we needing to consider the Condition field?

[kadinsayani]

We check the condition field to determine if a key is valid for instance type any, container, or virtual-machine.

[tomponline]

ok, so we really dont want to be comparing to arbitrary free-text values.

This seem super hacky to me.

[tomponline]

Currently, we add all keys from every config key group as long as they match the condition of instance type.

Do we make clear the link anywhere between the value of condition and how it affects auto complete?
It feels like this link has been only recently established in these changes and could easily be broken due to not making clear the link, and hard to detect (due to there being no tests for auto complete).

I wonder if lxd-metadata should be updated to test for valid "conditions" values from a slice it has so we can only use accepted ones.

Then we could expose those as constants and have them used as checks for the auto complete.

If we want to move away from comparing to strings found in metadata, we can grab the keys from instancetype.InstanceConfigKeysAny/VM/Container.

But that would then be restricted to keys known about by the client, and not by the server leading to situations where the client may suggest something the server doesnt support or miss out on suggesting something it does support.

Also, by checking for condition as it stands today, you're missing out on other instance fields like raw.idmap and security.idmap.* which have a condition of unprivileged container.

One acceptable workaround would be to have a list of prefixes that you can accept from the metadata API irrespective of condition.

[kadinsayani]

I'm in agreement with moving away from checking "condition" values.

But that would then be restricted to keys known about by the client, and not by the server leading to situations where the client may suggest something the server doesnt support or miss out on suggesting something it does support.

We can also consider checking the keys from the metadata API against instancetype.InstanceConfigKeysAny/VM/Container to deduce compatible instance types. Aren't the keys generated by lxd-metadata sourced from lxd/instance/instancetype/instance.go?

[tomponline]

Yes, but remember lxc would be built against a list at a point in time, but the server maybe newer and have additional keys only in metadata api

[kadinsayani]

What about adding a "supported instance type" field to the metadata? I'm trying to avoid hard coding a list of accepted keys based on instance type in the client, since these may not line up with the server. Also, there are cases where a prefix contains keys supported by containers and VMs. For example, the migration prefix contains migration.incremental.memory which is only supported by containers, and migration.stateful which is only supported by VMs.

[kadinsayani]

Another consideration for adding an instance type field to config keys in the metadata is the potential usability improvements that could be achieved in lxd-ui. I don't use it much so I'm not sure if completions are served when setting profile or instance config keys, but having an instance type field in the metadata could facilitate smart completions for config keys in the ui.

[tomponline]

Is it possible to split this pr into two, so we can merge the non contentious parts?

[kadinsayani]

Is it possible to split this pr into two, so we can merge the non contentious parts?

Sure thing. I've updated this PR and created #14702. Please note the addition of 5b7d222.