[BUG] meta-data is inconsistent depending on the URL used for access

[alexlovelltroy]

When meta-data is returned as part of a full cloud-init payload, several additional fields are added.

https://github.com/OpenCHAMI/cloud-init/blob/main/cmd/cloud-init-server/handlers.go#L138C1-L174C2

When meta-data is returned alone, it doesn't get the additional fields added.

These two calls should be equivalent.

[davidallendj]

I noticed when I include a meta-data property in my test.json, the meta-data is included in the responses with /{id}/meta-data, /groups/{name}, and /{id}:

Request to /{id}:

curl $CLOUD_INIT_URL/x3000c0b0n1                
{"name":"x3000c0b0n1","cloud-init":{"user-data":{"write_files":[{"path":"/etc/hello","content":"hello","group":"compute"}]},"meta-data":{"NID":1,"cloud_name":"OpenCHAMI","groups":{"compute":[{"hello":"world"}]},"xname":"x3000c0b0n1"},"vendor-data":null}

Request to /{id}/meta-data:

curl $CLOUD_INIT_URL/x3000c0b0n1/meta-data
groups:
  compute:
  - hello: world

Request to /groups/{name}:

curl $CLOUD_INIT_URL/groups/compute                    
name: ""
data:
- hello: world
actions:
  write_files:
  - content: hello
    path: /etc/hello

Finally, the test.json submitted with curl $CLOUD_INIT_URL/groups/compute [email protected]:

{
  "user-data": {
      "write_files": [
              {
                 "content": "hello",
                 "path": "/etc/hello"
              }
      ]
  },
  "meta-data": [
          {"hello": "world"}
  ]
}

Which fields should be included in the standalone meta-data payload? Am I missing something or doing something differently/unexpected?