Fix load balancer IP configuration for hcloud provider 1.56+

[arbianshkodra]

Summary

Fixes #1953

This PR addresses the load balancer network attachment IP issue that occurs when upgrading to hcloud provider v1.56.0+. The provider now validates that the load balancer IP is within the assigned subnet range and properly manages the IP lifecycle.

Changes

• Changed IP allocation: Use -2 (last usable IP in subnet) instead of hardcoded 254 in cidrhost() function
• Updated lifecycle management: Removed ip from ignore_changes block to allow proper IP management with hcloud provider 1.56+
• Added documentation: Included comments explaining the changes for future reference

Background

With hcloud provider v1.56.0, load balancers can now be assigned to specific network subnets, and the provider validates that attachment IPs are within the subnet IP range. The previous hardcoded value of 254 could fall outside the actual subnet range, causing the error:

Attachment IP (10.254.0.1) is outside subnet IP range (10.0.0.0/16)

Using -2 with cidrhost() ensures we always get the last usable IP within the actual subnet, regardless of subnet size.

Testing

• Tested with hcloud provider v1.56.0
• Verified that terraform plan no longer shows warnings or errors about IP ranges
• Confirmed load balancer network attachment is created successfully

Migration Notes

For existing deployments upgrading to this version with hcloud provider 1.56+:

The problem is that hcloud provider 1.56 won't let us fix the bad state through normal plan/apply - it validates and rejects the change. This is why you need to remove it from state first:

# Remove the bad resource from state
tofu state rm 'module.kube-hetzner.hcloud_load_balancer_network.cluster[0]'

# Or if using terraform:
terraform state rm 'module.kube-hetzner.hcloud_load_balancer_network.cluster[0]'

# Then apply to recreate with correct configuration
tofu apply  # or terraform apply

The load balancer network attachment will be recreated with the correct IP. There will be minimal disruption as the load balancer itself is not affected, only its network attachment.

[gemini-code-assist]

Summary of Changes

Hello @arbianshkodra, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue with load balancer IP configuration when using hcloud provider version 1.56.0 or newer. It updates the IP allocation logic to dynamically select a valid IP within the assigned subnet range and enables proper lifecycle management of the load balancer's network attachment IP, preventing errors and ensuring seamless operation with the updated provider.

Highlights

• IP Allocation Logic: Modified the cidrhost() function to use -2 instead of a hardcoded 254 to dynamically select the last usable IP in a subnet, ensuring compatibility with hcloud provider v1.56+.
• Lifecycle Management: Removed ip from the ignore_changes block in the hcloud_load_balancer_network resource, allowing the hcloud provider v1.56+ to properly manage the load balancer's IP lifecycle.
• Code Documentation: Added comments to init.tf to explain the changes made to the IP allocation and lifecycle management for clarity.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses the load balancer IP configuration issue with hcloud provider v1.56+ by using a dynamic IP from cidrhost and allowing the provider to manage the IP lifecycle. The changes are well-documented with comments and the PR description provides clear migration notes. My main feedback is to apply the same fix to a similar resource for the control plane load balancer, which appears to have been overlooked, to ensure consistency and prevent the same issue from occurring there.

[gemini-code-assist]

This change to use -2 in cidrhost is correct and makes the IP allocation more robust for different subnet sizes.

I noticed that a similar resource, hcloud_load_balancer_network.control_plane in control_planes.tf, still uses the hardcoded value 254 and also has ip in its lifecycle.ignore_changes block. This will likely cause the same issue this PR is fixing, but for the control plane load balancer.

Here is the relevant code from control_planes.tf:

resource "hcloud_load_balancer_network" "control_plane" {
  // ...
  ip                      = cidrhost(hcloud_network_subnet.control_plane.*.ip_range[0], 254)

  lifecycle {
    ignore_changes = [ip]
  }
}

To ensure consistency and prevent future errors, I recommend applying the same fix to the hcloud_load_balancer_network.control_plane resource in control_planes.tf as part of this PR.

[arbianshkodra]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly addresses the load balancer IP configuration issue with hcloud provider v1.56+ by updating the cidrhost function to use the last available IP and by allowing the provider to manage the IP address. The changes are well-documented with comments and the fix in modules/host/variables.tf is also a good improvement. I've found one potential issue in control_planes.tf where enable_public_interface has been added to ignore_changes, which would prevent a configurable variable from being updated. My suggestion is to remove it to ensure expected behavior.

[gemini-code-assist]

While removing ip from ignore_changes is correct for the hcloud provider v1.56+ update, replacing it with enable_public_interface seems unintended. This change will cause Terraform to ignore any future modifications to the var.control_plane_lb_enable_public_interface variable, which is likely not the desired behavior for a configurable parameter. If the intention was solely to remove ip from this lifecycle block, ignore_changes should be an empty list.

  lifecycle {
    # Removed 'ip' from ignore_changes to allow proper management with hcloud provider 1.56+
    ignore_changes = []
  }

[arbianshkodra]

/gemini review

[gemini-code-assist]

Code Review

This pull request correctly addresses an incompatibility with the hcloud provider v1.56.0+ by updating the load balancer network IP configuration. The changes are correct and consistently applied. I've added two comments: one suggesting a code simplification in control_planes.tf, and another regarding an unrelated but correct fix that was included in this PR. Overall, this is a solid improvement.

[gemini-code-assist]

Since ignore_changes is now an empty list, this lifecycle block is no longer necessary and can be removed to simplify the code. The explanatory comment is helpful, but it could be moved above the resource block if you feel it's important to keep for context.

[gemini-code-assist]

This is a good correction, changing default to description. The previous implementation was using the default attribute to hold a descriptive string, which is not its intended purpose.

However, this change is unrelated to the main goal of this pull request (fixing the load balancer IP configuration) and is not mentioned in the summary. To improve clarity and make reviews easier, it's best practice to keep pull requests focused on a single logical change. Please consider moving unrelated fixes like this to a separate PR in the future.