search

equinix-labs / metal-go

[Deprecated] Golang client for Equinix Metal
https://deploy.equinix.com/labs/equinix-sdk-go/
MIT License
3 stars 2 forks source link

Clean up spec for Metal Gateways #137

Closed ctreatma closed 4 months ago

ctreatma commented 1 year ago

Taken from a comment on #128.

There are a couple inline schemas for Metal Gateways, which leads to duplicated code, an inability to reuse objects across methods due to type mismatches.

The spec section that corresponds to FindMetalGatewayById200Response is here: https://github.com/equinix-labs/metal-go/blob/main/spec/oas3.fetched/paths/metal-gateways/id.yaml#L56-L58

oneOf:
- $ref: '../../components/schemas/MetalGateway.yaml'
- $ref: '../../components/schemas/VrfMetalGateway.yaml'

This chunk should be moved to a file under components/schemas/, but we'd need a good name for it. Maybe rename the existing MetalGateway.yaml to NonVrfMetalGateway.yaml? Is there a better name we could come up with? Names like GenericMetalGateway.yaml (for the new component) have caused concern in the past, but I'm not sure how to give the existing MetalGateway.yaml a more specific name without referencing VRF.

There is a similar inline schema inside MetalGatewaysList.yaml; that one uses an anyOf instead of a oneOf, but we should really use the same relationship in both places so that we can improve reused of our components.

ctreatma commented 1 year ago

Normally I'd say we should use a oneOf, since we expect the API to return either a MetalGateway or a VrfMetalGateway, but given that non-VRF gateway properties are a subset of VRF gateway properties, aligning on anyOf may lead to a better user experience.

ctreatma commented 1 year ago

After some experimentation, we've found that if we include=ip_reservation, we can rely on the IP reservation to identify what type of Metal gateway was received (a VRF gateway has an IP reservation with type vrf, whereas a non-VRF gateway has an IP reservation with one of the types [global_ipv4, public_ipv4, private_ipv4, public_ipv6]).

That means in the near term we could keep the oneOf construct, which is IMO preferable, and document that the IP reservation must be included to find the type.

For a more permanent fix we could introduce a type field on Metal gateways on the API side so that there is a way to determine what kind of Metal gateway was received without needing to include other resources.

codinja1188 commented 1 year ago

The same kind of issue, clean up spec for IPReservations too.

https://github.com/equinix/metal-cli/issues/351

codinja1188 commented 1 year ago

Same kind of issue,

 Vasubabus-MacBook-Pro:bin vasubabu$ ./metal conn get -O "4d12f460-8c5e-43ea-986d-529d328815ee"
Error: could not list Project Interconnections: data matches more than one schema in oneOf(VirtualCircuit)
codinja1188 commented 1 year ago 
Vasubabus-MacBook-Pro:bin vasubabu$ ./metal conn get -O "4d12f460-8c5e-43ea-986d-529d328815ee"
+++ Org IDError: could not list Organization Interconnections: data matches more than one schema in oneOf(VirtualCircuit)
Vasubabus-MacBook-Pro:bin vasubabu$ ./metal conn get -p 5211fb64-1e5b-402f-a904-f86427a5dc55
+++ Project IDError: could not list Project Interconnections: data matches more than one schema in oneOf(VirtualCircuit)
ctreatma commented 4 months ago

This repo is deprecated and a corresponding issue has been created in equinix/equinix-sdk-go