Subnet id should put server in a subnet

[rightaway]

From https://github.com/hetznercloud/terraform-provider-hcloud/issues/340 subnet_id doesn't actually put a server in a subnet which is leading to more complicated terraform code when you have many servers on many subnets. We'll have to use cidrhost and manually get an index to use with it.

If you've got many servers that are created differently and not in a loop, it will be a problem to make sure we're manually choosing them properly. For example not duplicating them or setting a value that is beyond the range of the subnet. This is a very fragile approach and not one hetzner should be encouraging.

Hcloud users shouldn't be made to calculate something that hetzner should be able to if we say which subnet_id we want. Terraform is meant to decrease bugs like this but the way hetzner handles subnets will increase them.

This should really be fixed. Even though it's documented it is not what you would expect and really takes away from the ease of setting up infrastructure that terraform is meant to do. It's not what people are used to in networking with other cloud providers.

[fhofherr]

Hi @rightaway,

thanks for your issue report. We realize that this is an inconvenient aspect of the current network implementation. Unfortunately this is something we cannot fix in the Terraform provider alone.

The way the Hetzner Cloud API currently works is that subnet membership is determined by the network ID and the IP address. Additionally subnets currently cannot be directly identified in our API.

At the moment the best we could do in the Terraform provider would be assignment to subnetworks based on the derived subnet ID we compute. We could then select an IP address very much in the way you described. However, since we cannot know how users invoke Terraform we run the risk of race conditions when servers are assigned to the same subnetwork in parallel. In this case it may happen that we try to assign the same IP address within the subnetwork to two different servers. We do not want to take this risk.

While I understand that this is not satisfying to you, we currently feel unable to provide a Terraform provider only solution to the issue. I will check with my colleagues whether it is possible to improve the way our API behaves. Please understand though, that I am not able to give you a timeline as to when we will be able to change this.

[rightaway]

If it would eventually be possible to identify subnets directly in the API that would be a great addition to the API and enable a lot of useful features. One example is being able to refer directly to a subnet id in firewall rules in provisioning system (not just in hetzner firewall).

Setting ip addresses manually requires a lot of coordination between various aspects of our infrastructure so it would be better if it could work similar to DHCP where ip addresses are assigned automatically based on which subnet they belong to.

I understand it could take a long time to make this solution but hoping the colleagues will think it's a feature that should be added at some point. Many new use cases would be possible that for the moment we have to stick to other cloud providers to do. Would prefer to transition everything to hetzner for simplicity.

[tenczardavid]

Is there a workaround currently which could be proposed for this issue? I tried a workaround implementation but I ran into an other limitation with data sources (opened feature request: https://github.com/hetznercloud/terraform-provider-hcloud/issues/420).

Any other idea other than manually coordinating this?

[dcardellino]

Also ran into this issue. Any update here?

[github-actions[bot]]

This issue has been marked as stale because it has not had recent activity. The bot will close the issue if no further action occurs.

[apricote]

Closing as the required feature has not been implemented in the API. It is a known feature request to the responsible team.