You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re using Discussions as a place to connect with other members of our community. We hope that you:
Ask questions you’re wondering about.
Share ideas.
Engage with other community members.
Welcome others and are open-minded. Remember that this is a community we
build together 💪.
To get started, comment below with an introduction of yourself and tell us about what you do with this community.
NOTE: This discussion originated from the pull-request equinix/terraform-provider-metal#165 for the Equinix Metal Provider repository which is now deprecated. During the deprecation process we have migrated issues and PRs to this repository since the Equinix provider has full support for existing Terraform managed Metal resources, however that PR contains content that we consider is more appropriate to continue the discussion here before resuming efforts.
This allows making sure that every new device will have a unique hostname. There are a number of distributed systems like Kubernetes, Ceph, Redpanda, .. that assume that each host is unique by its hostname.
Using random_string to add a suffix to the hostname is not enough because it doesn't guarantee that the random_string will be re-created if the metal_device is (eg: user_data change, resource was deleted manually, or tainted).
This PR was inspired by the aws_s3_bucket resource.
In the original post there are several reasons for and against adding this feature. IMO, in general terms, terraform should always mimic the behavior of the API, this helps API users to start using terraform without extra pre-knowledge and developers take advantage of auto-generated documentation from API specs. However, this specific case is different because UI portal offers a similar approach for creating devices in batch. Should terraform then add this functionality? If so, what would be the best approach?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
👋 Welcome!
We’re using Discussions as a place to connect with other members of our community. We hope that you:
build together 💪.
To get started, comment below with an introduction of yourself and tell us about what you do with this community.
NOTE: This discussion originated from the pull-request equinix/terraform-provider-metal#165 for the Equinix Metal Provider repository which is now deprecated. During the deprecation process we have migrated issues and PRs to this repository since the Equinix provider has full support for existing Terraform managed Metal resources, however that PR contains content that we consider is more appropriate to continue the discussion here before resuming efforts.
Original post created by @zimbatm :
In the original post there are several reasons for and against adding this feature. IMO, in general terms, terraform should always mimic the behavior of the API, this helps API users to start using terraform without extra pre-knowledge and developers take advantage of auto-generated documentation from API specs. However, this specific case is different because UI portal offers a similar approach for creating devices in batch. Should terraform then add this functionality? If so, what would be the best approach?
Beta Was this translation helpful? Give feedback.
All reactions