Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: Always require subnet id when depending on a network id #980

Open
jooola opened this issue Aug 27, 2024 · 0 comments
Open

[Feature]: Always require subnet id when depending on a network id #980

jooola opened this issue Aug 27, 2024 · 0 comments

Comments

@jooola
Copy link
Member

jooola commented Aug 27, 2024

What whould you like to see?

When working with networks, we usually depend on the parent network and require the users to add an extra depends to wait for the subnet to be deployed before taking actions. For example:

resource "hcloud_load_balancer_network" "load_balancer" {
  load_balancer_id = hcloud_load_balancer.load_balancer.id
  network_id       = hcloud_network.network.id
  ip               = "10.0.1.5"

  # **Note**: the depends_on is important when directly attaching the
  # server to a network. Otherwise Terraform will attempt to create
  # server and sub-network in parallel. This may result in the server
  # creation failing randomly.
  depends_on = [
    hcloud_network_subnet.srvnetwork
  ]
}

I propose to require the subnet_id instead of the network_id, which allows us to remove the depends on and perform an additional validation for the ip, since the subnet ID also holds both the network ID and the ip_range in a CIDR notation.

Alternatively, we could require both network id and subnet id, similar to how the hcloud_server_network resource is working, which makes it even more explicit.

This will probably be a breaking change, but the field may be added first without being required, and once we release a new major version, we mark the field as required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants