feat(robot): allow Robot support without API credentials for IP-based LB targets#1163
Conversation
|
Hey there! This is my first contribution to HCCM and I tried to make it as clean and meaningful as possible. I added tests and also tested the feature in a Talos Cluster based on Hetzner dedicated servers, as well as my CAPI-based cluster using HCloud instances. Please let me know if I missed anything or if the motivation for this feature is unclear. |
lukasmetzner
left a comment
There was a problem hiding this comment.
Hey, I did a quick review and left some suggestions.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1163 +/- ##
==========================================
- Coverage 68.55% 65.67% -2.89%
==========================================
Files 24 24
Lines 2643 2657 +14
==========================================
- Hits 1812 1745 -67
- Misses 656 744 +88
+ Partials 175 168 -7
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
The e2e tests failing is normal here due to missing permissions. Once everything is resolved in the PR I will manually run them on my machine. If you have the resources to test your changes on the Cloud and Robot platform, feel free to share the results, but as this induces costs, don't feel obligated to do so. |
b027622 to
79c707e
Compare
|
Thanks again for your review and the time you put into adjusting my code! I adopted your changes and adjusted tests accordingly. Regarding the e2e test: Would be great if you could run them for me! I tested the changes on a Talos cluster with Hetzner dedicated servers connected via vSwitch, as well as a CAPI-based cluster with HCloud instances (to verify no regressions). |
79c707e to
f57cdf6
Compare
|
Fixed lint complaint and rebased the commit. |
…targets Previously, enabling Robot support (`ROBOT_ENABLED=true`) required both `ROBOT_USER` and `ROBOT_PASSWORD` to be set. This made it impossible to use Robot nodes as IP-based load balancer targets without providing Robot API credentials. With this change, Robot credentials become optional. When no credentials are provided, the load balancer reconciler derives IP targets directly from the Kubernetes Node objects' InternalIP instead of querying the Robot API. This is sufficient for setups where the node's InternalIP (e.g. a vSwitch private IP) is the correct LB target address. Partial credentials (only user or only password) are still rejected as a likely misconfiguration.
f57cdf6 to
3bf2c02
Compare
|
Hey, @robertlemke took me a bit to find the time to test this manually, but looking good so far. I have a small question regarding your use-case. For the InternalIPs, do you use IPs from a Hetzner Cloud Private Network, which the Robot server is connected to via a vSwitch? |
|
Hey @lukasmetzner, sorry for the hassle and thanks again for your time!
Yes, exactly! Our Robot servers are connected to a Hetzner Cloud Network via vSwitch. The nodes get their vSwitch IP assigned as InternalIP through the Talos machine configuration. The CCM then uses these IPs as Load Balancer targets which works perfectly since the LB and the Robot servers are on the same private network. This is the main use case we had in mind: you get full Load Balancer integration for Robot servers without needing Robot API credentials, as long as private networking via vSwitch is set up. Does that make it a bit clearer? Feel free to ask, if you need to know more. Cheers! |
When
robot.enabledis set but noROBOT_USER/ROBOT_PASSWORDare provided, the HCCM now derives IP targets directly from the Kubernetes Node'sInternalIPinstead of querying the Robot API. This is useful for setups where Robot servers are connected via vSwitch and only the service controller is needed.Existing behavior is unchanged when credentials are provided. Partial credentials (only user or only password) are rejected during validation.
Fixes: #1162