equinix / equinix-sdk-go Goto Github PK
View Code? Open in Web Editor NEWGolang client for Equinix APIs
Home Page: https://deploy.equinix.com/labs/equinix-sdk-go
License: MIT License
Golang client for Equinix APIs
Home Page: https://deploy.equinix.com/labs/equinix-sdk-go
License: MIT License
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.
As of now, this repo is set to private/internal while we fill in some gaps to make it ready for other teams & for external customers. Once this is ready for public consumption, we will delete the repo and recreate it to ensure that any unnecessary releases/tags/etc. are cleaned up.
Before this goes public, we need to:
README
with customer-facing informationCONTRIBUTING
document that includes contribution guidelinesDEVELOPMENT
document that includes: how to get set up for local development, how to onboard a new service, how to update an existing service, how to cut a releaseexamples
to use this SDK instead of metal-go to demonstrate that this is a drop-in replacementmain
Steps for going public:
metal-go
releaseequinix-labs/metal-go
to this repoequinix-labs/metal-go
and include a link to this repometal-go
Labs page with a page for this SDKThe FindIPReservations
endpoint only has an Execute()
method even though the endpoint is paginated.
The ExecuteWithPagination
method is missing because the request object does not have a page
parameter, which means there's no way to tell this generated client to fetch pages beyond 1.
The API spec for the findIPReservations
path needs to be updated to reference the page
parameter. There is an example of referencing the page
parameter in the findProjectEvents
endpoint.
When using client-side filtering against a paginated resource list, the pagination helpers could accept criteria functions to determine if pagination can be concluded early.
If there are 1000 devices that I need to sift through to find the one with a particular set of tags (kubernetes-sigs/cluster-api-provider-packet#630), I should be able to take advantage of pagination helpers and not request 100 pages of data if my single desired matching result was found on page 1.
See related packngo issue equinixmetal-archive/packngo#206
Copied from equinix-labs/metal-go#120.
We have an unnecessary AuthTokenUser
model that is identical to the User
model aside from the description. There is also an unnecessary AuthTokenProject
model that is identical to the Project
model aside from the description.
These models are generated because the AuthToken
spec uses allOf
to inject a description for the user and project properties for documentation purposes. This kind of structure is fine for redoc, but doesn't work well with code generators.
We need to find a different way to indicate that user tokens have a user
and project tokens have a project
that doesn't result in the creation of unnecessary duplicate models.
Equinix Metal deprecated facilities in favor of metros in April 2023. As of January 2024, facilities have been (largely?) removed from Equinix Metal; to avoid confusion and simplify code, we should remove the deprecated facility-related properties from this SDK entirely.
This could prevent cancelation
This is a finding from investigation on equinix-labs/metal-go#137.
This also relates to equinix-labs/metal-go#128.
The Metal Gateway API endpoints are all specified as returning the following schema:
oneOf:
- $ref: ./MetalGateway.yaml
- $ref: ./VrfMetalGateway.yaml
In OpenAPI 3, a oneOf
has to match exactly one of the nested schemas, but by default, the Metal API response from Metal Gateway endpoints does not include enough information to differentiate between gateways (anything that matches the VrfMetalGateway schema will also match the MetalGateway schema).
This could be addressed with API changes, or possibly with spec changes that do not require an API change, but in the meantime the best workaround we have found is to add the following to all Metal Gateway API requests made with this SDK:
.Includes([]string{"ip_reservation"})
This workaround instructs the API to include IP reservation details in the API response. IPReservation and VrfIpReservation can be distinguished by the SDK, which enables the SDK to determine the gateway type (because MetalGateway has an IPReservation and VrfMetalGateway has a VrfIpReservation.
NOTE: because the Metal Gateway deletes are async, you also need to include the IP reservation in delete requests to avoid a response validation error.
You can see an example of the .Include()
call here: https://github.com/equinix/terraform-provider-equinix/blob/611e78a32a865aa374d2e4896cd0978252b983c4/internal/resources/metal/gateway/resource.go#L173
Currently when a service is onboarded to this SDK, we create a service-specific workflow that regenerates the code for that service in order to validate changes in Pull Requests. However, since this is a single SDK we need to ensure that there are no unexpected interactions with other services.
Remove the service-specific codegen workflows and replace them with a single workflow that runs make generate-all
to regenerate the code for all onboarded services.
All ASN fields (peer_as
, origin_as
(below), peer_asn
, local_asn
, asn
, bgp_neighbor_asn
) should be updated to int64 with a min:0
and max:2^32
(since there is no uint32 type in OAS3).
The fabric-go
GitHub Actions workflows were updated to allow the sync
workflow to automatically discover the latest version of the Fabric v4 OpenAPI spec, download that version, and then regenerate code from the new spec. This reduces manual effort to keep the SDK aligned with API changes.
This is the PR that updated the fabric-go
automation to pull in the latest Fabric v4 spec instead of requiring a manual PR to bump the spec version number: equinix-labs/fabric-go#30
It would be nice to replicate that work here so that we can avoid reintroducing the requirement for a manual spec version bump and so that we can build some momentum around using the Swagger API registry URL to discover new Equinix service versions (and possibly enable discovery of the services themselves).
While retrieving connections for a project, using endpoint https://api.equinix.com/metal/v1/projects/{project_id}/connections
and below sdk, getting json unmarshalling error for speed
parameter for the connection
apiClient.InterconnectionsApi.
ProjectListInterconnections(context.Background(), project.GetId()).
Execute()
Note: Any available value of the speed (ex: 5000000 etc) is provided, the error remains the same
Error:
json: cannot unmarshal number 10000000000 into Go struct field _InterconnectionList.interconnections of type int32
There seems to be a mismatch in the schema validation on the server and published api doc. Need to fix the marshalling of speed parameter from the server
In terraform-provider-equinix
, there's a place where we use the href
of a project's organization to get the organization ID without having to include the full organization, which would increase response latency.
The code to do that is more verbose than necessary because the Organization
schema does not declare an href
property, so we have to read that property from AdditionalProperties
and then, because AdditionalProperties
can contain properties of any type, we have to cast the href
property to a string.
If the Organization
schema in the Metal API spec were updated to declare an href
property that is type: string
, we could simply do organization.GetHref()
.
Copied from equinix-labs/metal-go#154
The API spec says that the type
of a drive in a plan spec must be one of the following:
enum:
- HDD
- SSD
- NVME
However, the API can return the value NVMe
, as mentioned in this PR comment from metal-cli: equinix/metal-cli#350 (comment)
The spec needs to be updated so that all possible values for type
are documented accurately in the spec.
The Metal API spec does not specify a backend_transfer_enabled
property for the Project
component, which means we can't read it in the terraform provider: https://github.com/equinix/terraform-provider-equinix/pull/517/files#diff-06c1ecab9b2a05b42b2d8693260c74b084d6cdd8902c905af5c3c8963cd1cac5R150
It is, however, included in the spec for ProjectUpdateInput
, so we can change the value: https://github.com/equinix/equinix-sdk-go/blob/main/services/metalv1/model_project_update_input.go#L23C2-L23C24
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
This repository currently has no open or pending branches.
.github/workflows/release.yaml
actions/setup-go v5
actions/checkout v4
cycjimmy/semantic-release-action v4
.github/workflows/sync-eiav2.yaml
actions/setup-go v5
actions/checkout v4
peter-evans/create-pull-request v6
mshick/add-pr-comment v2
mshick/add-pr-comment v2
.github/workflows/sync-fabricv4.yaml
actions/setup-go v5
actions/checkout v4
peter-evans/create-pull-request v6
mshick/add-pr-comment v2
mshick/add-pr-comment v2
.github/workflows/sync-metalv1.yaml
actions/setup-go v5
actions/checkout v4
peter-evans/create-pull-request v6
mshick/add-pr-comment v2
mshick/add-pr-comment v2
.github/workflows/test-codegen.yaml
actions/setup-go v5
actions/checkout v4
golangci/golangci-lint-action v6
.github/workflows/validate_pr.yaml
amannn/action-semantic-pull-request v5
marocchino/sticky-pull-request-comment v2
marocchino/sticky-pull-request-comment v2
templates/.github/workflows/sync.yaml
actions/setup-go v5
actions/checkout v4
peter-evans/create-pull-request v6
mshick/add-pr-comment v2
mshick/add-pr-comment v2
go.mod
go 1.19
github.com/stretchr/testify v1.9.0
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.