metalv1 missing the metadata SDK

[deitch]

The metalv1 section of this SDK replaces the packethost/packngo SDK, which has been deprecated at least since Dec 2023 (this commit).

The metalv1 SDK in this archive is missing the packethost/packngo/metadata section. Per the link, it provides an ability to interface with the local metadata endpoint from directly on hosts. I.e. it does not use the authenticated public Metal endpoint, but rather the equivalent of curl metadata.equinixmetal.com from within a device itself and then processing it.

[displague]

Ideally, this would start with a published API spec for the Metadata service and visibility alongside (not necessarily within) the other Equinix API specs, such as https://deploy.equinix.com/developers/api/metal/

within: I've chatted with @ctreatma before about how some of metadata structure is represented within the Metal API Device Instance object. Being able to reference the same object for both API roots would be neat. A spec can contain multiple roots and authentication patterns, the endpoints defined for these roots could share schema definitions. Being neat doesn't make this the best way to represent the Metadata API spec.

alongside: The metadata service is currently described at https://deploy.equinix.com/developers/docs/metal/server-metadata/metadata/, but no formal definition is offered today, which is a dependency of the generated SDKs and generated API docs.

(cc @DailyAlice)

[deitch]

Yeah, that would be best. If the API paths and content were identical across both, then it would be much simpler.

[ctreatma]

In my opinion the most straightforward path for adding metadata API support in this SDK is a separate spec. Despite any similarities in response structure in certain cases for certain endpoints, my understanding is that the metadata API is a truly separate thing. If/when it fails it may not fail in the same way that metalv1 does, and as a separate entity it could change in different ways and at different times than metalv1.

For comparison, the github.com/packethost/packngo/metadata package is only tied to the parent packngo package by repo structure. The metadata package does not reuse any code from packngo, so there would be no increase in code duplication by generating a metadata client from a separate metadata spec. The benefit of having an official, published spec would be clear ownership and maintenance of the metadata client going forward, but that would take time. In a pinch, the metadata package could be extracted from packngo and published elsewhere as a separate, hand-written client.