Giter Site home page Giter Site logo

equinix / equinix-sdk-go Goto Github PK

View Code? Open in Web Editor NEW
2.0 4.0 4.0 38.92 MB

Golang client for Equinix APIs

Home Page: https://deploy.equinix.com/labs/equinix-sdk-go

License: MIT License

Makefile 1.98% Shell 2.62% Python 2.67% Mustache 92.73%
baremetal equinix equinix-metal equinix-metal-api go golang

equinix-sdk-go's People

Stargazers

 avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

equinix-sdk-go's Issues

metalv1 missing the metadata SDK

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.

Public readiness checklist

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:

  • Fill in the README with customer-facing information
  • Add a CONTRIBUTING document that includes contribution guidelines
  • Add a DEVELOPMENT 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 release
  • Update examples to use this SDK instead of metal-go to demonstrate that this is a drop-in replacement
  • Enable branch protection on main

Steps for going public:

  • Cut a release that only includes the module name / package structure change (is otherwise identical to the last metal-go release
  • Transfer remaining issues from equinix-labs/metal-go to this repo
  • Deprecate equinix-labs/metal-go and include a link to this repo
  • Update or replace metal-go Labs page with a page for this SDK

[Metal] Can't load all pages for the FindIPReservations endpoint

The 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.

[Metal] pagination should offer early escape criteria

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

[Metal] Remove AuthTokenUser and AuthTokenProject models

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.

[Metal] default Metal Gateway responses do not match the API spec

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

Replace individual service codegen tests with a test that generates the whole SDK

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.

[Fabric] replicate spec version syncing from `fabric-go`

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).

[Metal] Interconnections retrieve fails with schema error

What problem are you facing?

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

How could the Equinix Metal Go SDK help solve this problem?

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

[Metal] `Organization` model does not declare an `href` property

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().

[Metal] Can't read `backend_transfer_enabled` property for a Metal project

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

Dependency Dashboard

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.

Detected dependencies

github-actions
.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
gomod
go.mod
  • go 1.19
  • github.com/stretchr/testify v1.9.0

  • Check this box to trigger a request for Renovate to run again on this repository

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.