packngo icon indicating copy to clipboard operation
packngo copied to clipboard

update metadata to latest structure

Open displague opened this issue 5 years ago • 4 comments

TODO

  • tests should unmarshal the new structs (fix the ipnet tests)
  • provide examples of the new structures in the text fixture
  • provide comments for each field (and examples when vague)

prior art (https://github.com/packethost/packetmetadata/blob/master/packetmetadata/packetmetadata.go) (no longer online)

displague avatar Dec 13 '20 00:12 displague

To test this means to run a device and try to read the metada via GetMetadataFromURL?

t0mk avatar Dec 14 '20 10:12 t0mk

To test this means to run a device and try to read the metada via GetMetadataFromURL?

@t0mk, yes.

Or running metadata.GetMetadata()

This package doesn't seem to be getting much attention or use. I would like to see us use it in https://github.com/packethost/packngo/issues/189 so we could self-discover project and organization values for clients like the CCM which are expected to be run from Equinix Metal devices (for the benefit of fewer configuration parameters in cases where it can be detected).

I hadn't really looked at GetMetadata or GetMetadataFromURL before you asked. I think we'll want to revise these functions to take a context.Context parameter.

displague avatar Jan 06 '21 14:01 displague

@displague I'm testing this. I get

panic: json: cannot unmarshal number into Go struct field .storage.disks.partitions.size of type string

For

	// Partition size is sometimes str and sometimes int
	/*
	 "storage": {
	    "disks": [
	      {
	        "device": "/dev/sda",
	        "wipeTable": true,
	        "partitions": [
	          {
	            "label": "BIOS",
	            "number": 1,
	            "size": 4096
	          },
	          {
	            "label": "SWAP",
	            "number": 2,
	            "size": "3993600"
	          },
	          {
	            "label": "ROOT",
	            "number": 3,
	            "size": 0
	          }
	        ]
	      }
	    ],
	*/

t0mk avatar Jan 07 '21 11:01 t0mk

@t0mk I have an internal issue filed against this behavior. It is currently possible for the size response to be any of 0, "1", "123MB". I suppose the correct behavior for the client is to translate the possible responses into an integer of fixed units (bytes?).

displague avatar Jan 11 '21 21:01 displague