Closed ctreatma closed 4 months 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.
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.
The same kind of issue, clean up spec for IPReservations too.
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)
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)
This repo is deprecated and a corresponding issue has been created in equinix/equinix-sdk-go
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-L58This chunk should be moved to a file under
components/schemas/
, but we'd need a good name for it. Maybe rename the existingMetalGateway.yaml
toNonVrfMetalGateway.yaml
? Is there a better name we could come up with? Names likeGenericMetalGateway.yaml
(for the new component) have caused concern in the past, but I'm not sure how to give the existingMetalGateway.yaml
a more specific name without referencing VRF.There is a similar inline schema inside
MetalGatewaysList.yaml
; that one uses ananyOf
instead of aoneOf
, but we should really use the same relationship in both places so that we can improve reused of our components.