Why does the script precompute private ipv4's instead of having them auto assigned?

[valkenburg-prevue-ch]

Hi,

I see that the script goes to great lengths to precompute the private ips in the various subnets. I've seen this in other projects too. Could this be a relic from the past? One can assign an hcloud_server to a private network and let the private ip be auto assigned. This would remove quite a bit of book keeping, and makes it much easier to add anything to the network.

I have not been able to find bits of code the depend on knowing the private ip before the nodes are created, but perhaps I missed something.

Any thoughts?

[valkenburg-prevue-ch]

I checked that indeed auto-assigning works fine, consider this PR: #542

I'm open to discussion, should anyone object to the pr.

[valkenburg-prevue-ch]

Related question, though: why should control plane and agents be on different subnets? Does that make any difference anywhere?

[mysticaltech]

If I remember well, we tried mixing it up at the beginning, but if I remember well, there was also an issue when it could give the same IP when two servers were created at the same time. Now, maybe that has been fixed, as I do not see mentions of it anymore! Honesly, that is a vague memory.

But the way it is now is also clear, as each nodepool corresponds to a subnet. It's more organized, and I guess makes the underlying routing easier for the CNI. Just suppositions.

But definitely, if they can give the IP dynamically in the right subnet, it would be great to move to that.

[mysticaltech]

Please @valkenburg-prevue-ch, feel free to open a ticket to Hetzner!

[ifeulner]

It makes sense to have different subnets at least for control nodes and agents, in a production installation you would have a firewall between these node types.
But IP handling in general is an open issue, as we should also allow configuration options for pods, services, etc.
Besides that I would prefer to have as much automatic assigning as possible...

[mysticaltech]

@ifeulner Definitely, automatic is better, but as explained in this comment, we did not have a choice here.

[valkenburg-prevue-ch]

It's been a while, but I finally got around contacting support and now reporting back here. In short: auto-assigning IPs to different pre-created subnets is not going to be supported soon, but it is on Hetzner's radar as per this new issue: hetznercloud/terraform-provider-hcloud#672 .

Dear customer,

this is not easily possible with our current API, as the relevant endpoint only allows assigning a server to a network, not to a specific subnet. Passing an IP "bypasses" this, but someone needs to calculate that IP, right now this responsibility is passed to you as the users of the terraform module.

I talked to the responsible team for this endpoint and they stated that they have no plans to support assigning a server into a specific subnet at this time.

I have opened an issue on our public GitHub issue tracker that explains the problem, and we are open to pull requests that implement this.

hetznercloud/terraform-provider-hcloud#672

Mit freundlichen Grüßen / Kind regards

Julian

---

Dear madam, sir,

as per
https://registry.terraform.io/providers/hetznercloud/hcloud/latest/docs/resources/server_network#argument-reference
, you state "subnet_id - (Optional, string) ID of the sub-network which
should be added to the Server. Required if network_id is not set. Note: if
the ip property is missing, the Server is currently added to the last
created subnet."

Is there any chance this issue in the note can be repaired? That is, auto
ip assignment on any chosen pre-existing subnet, rather then overriding the
subnet_id to be the last created subnet? Our project currently pre-computes
all ips of the created instances, but this is quite some code to maintain
and makes it cumbersome to add new features.

Many thanks in advance!

Kind regards,
Wessel

[mysticaltech]

@valkenburg-prevue-ch Wonderful, well done! Apricot (the handle for Julian I guess) is pretty active. This ball has a good change of rolling 🤞🤞