Skip to content
This repository has been archived by the owner on Feb 23, 2024. It is now read-only.

Equinix Metal provider #279

Closed
displague opened this issue Oct 29, 2020 · 7 comments
Closed

Equinix Metal provider #279

displague opened this issue Oct 29, 2020 · 7 comments
Labels
meta Related to the project or organization

Comments

@displague
Copy link
Member

displague commented Oct 29, 2020

The name of this provider is currently packet. Since Packet is now Equinix Metal, the provider and all of the resources should be renamed appropriately.

What would the name be? equinix-metal
Here is an example of a hyphenated provider and modules: https://registry.terraform.io/providers/hashicorp/kubernetes-alpha/latest.
This provider should not be confused with https://github.com/equinix/terraform-provider-equinix (which should perhaps be renamed to equinix-fabric)

What will happen to this repository?
Eventually, this project will move to another org name, even if it persists as a copy with the packet name. It is therefor tricky to

My current thinking is:

  • Provide some final packet_ release. This should include deprecation messaging that the provider has been renamed and should offer instructions for transitioning. This messaging should be included in the README.md as well as the Terraform registry's provider documentation index page.
  • Move the repo to the new org (github provides redirects)
  • Rename the repo to the new name (github provides redirects)
  • Rename the resources/documentation
  • Add a message to the README about the rename and include transitioning notes. Include notes on how users can continue to use the latest packet_ releases.
  • rename the resources and URLs (github, registry, ci/cd configuration)
  • Create a new Terraform registry account
  • Tag the release

Existing packet users should be able to easily convert their existing configurations from packet to equinix_metal.

@t0mk
Copy link
Contributor

t0mk commented Oct 29, 2020

I think equinix-metal is proper, there are providers with hyphen in the name. Too bad the other equinix provider is not prefix-distinguishable.

There's also a lot of "Packet" in the function names, especially in the tests. Also the Auth Token envvar has Packet in it, and there's packngo.

Maybe it would be good to start from packngo and rename it to equinix-go-sdk or sth.

@displague
Copy link
Member Author

displague commented Oct 29, 2020

Too bad the other equinix provider is not prefix-distinguishable.

I chatted with @mikouaj about the Equinix provider, it is a unified provider and other resources will fit in there when added.

Metal is not a good fit for that provide, currently. This is something to reconsider when the metal API authentication follows the conventions of the generalized API used by the Equinix provider.

equinix-go-sdk

This is probably a conversation to start on packngo.

There are a few rename options, github.com/equinixmetal/equinix-metal-go/ or perhaps equinixmetal/equinix-metal-sdks/go (one repo with multiple providers, it might be hard to get Ruby, Python, Java/Maven, Go, NPM, and other tools to agree on the root directory structure, but this would make for a convenient way to maintain the various bindings.)

We may want to keep packngo alone and only redirect it to a new org. This will prevent breakage if we prefer to split the project up into concise packages (and not park everything in the root).

If we establish a new project, metal/v1/ might be a convenient base path.

  • metal/v1/clients/metal/metal.go
  • metal/v1/clients/metadata/metadata.go
  • metal/v1/services/device/device.go
  • metal/v1/models/device/device.go

This layout isn't something I've put too much thought into. One drawback is that you need to specify different package names.

Ultimately, it may be better to start the new project with Swagger generated models and services and layer helpers on top of that.

Let's move this conversation to packngo.
equinixmetal-archive/packngo#213

@displague
Copy link
Member Author

The equinix namespace and provider are now available: https://registry.terraform.io/namespaces/equinix

@displague displague added the meta Related to the project or organization label Nov 5, 2020
@displague
Copy link
Member Author

The new repository can change to the default branch of default, and can leave the master branch behind on this packethost fork of the project which should be archived after providing users ample time to migrate to the new project.

We may still see issues filed against this repository during the transition. With this repository being a fork of the terraform-provider-equinix-metal repo, we will be able to easily port those changes over as pull-requests.

@displague
Copy link
Member Author

This is now cleared to move. I will have to update the equinix-metal branch with the latest changes so that it can be merged into the main branch.

@displague
Copy link
Member Author

Redirects from packethost/terraform-provider-packethost to equinix/terraform-provider-equinix-metal won't withstand a fork at packethost/terraform-provider-packethost.

Since we don't get the benefit of redirects, I think the cleaner approach will be to create a new repo at equinix/terraform-provider-equinix-metal. This will also provide a better experience around release artifacts, since the new repo will not have any and the old repo will retain its artifacts.

@displague
Copy link
Member Author

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
meta Related to the project or organization
Projects
None yet
Development

No branches or pull requests

2 participants