✨ Bring your own network

[johannesfrey]

What this PR does / why we need it:
This PR makes it possible to "adopt" a pre-existing network by passing its ID to hetznerCluster.spec.hcloudNetwork.id instead of the network being created during cluster creation. Furthermore, during cluster deletion it only deletes the attached network if it does not have the owned label attached to it (currently the only way here to discriminate between a CAPH-managed network and an unmanaged one).

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #762

Special notes for your reviewer:
This has been lingering around for a while untouched on my fork and I decided to rebase it onto the current main branch. Please consider this as a first attempt to approach this topic as a whole. I also tried to already add some unit tests. I guess it also might require some e2e tests!? No idea if this is the desired way to do this and about other side-effects I did not see. So looking forward for feedback or any pointers. And also feel free to push changes to the PR, as I'll be pretty occupied with other things almost the whole September. Just wanted to push this out there already for you to take a look at 🙂

The most controversial changes so far:

• Making hcloudNetwork.id mutually exclusive with cidrBlock, subnetCidrBlock and networkZone
• Replacing kubebuilder defaulting/validation special tags with custom defaulting/validation, which makes the webhook more complex
• Changing cidrBlock, subnetCidrBlock and networkZone to be pointers (I guess this could also be done with empty strings, but pointers make it possible to be not shown at all, when not provided)
• Labels are shown in the NetworkStatus in order to check if it's managed or unmanaged

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

TODOs:

• squash commits
• include documentation
• add unit tests

[janiskemper]

In general this approach seems good to me. Thanks a lot for this contribution!

@guettli @batistein what's your opinion?

[janiskemper]

Thanks a lot again for this PR @johannesfrey. I think we can merge it if you follow the suggestions I gave. It's really good work!

[johannesfrey]

Thanks a lot again for this PR @johannesfrey. I think we can merge it if you follow the suggestions I gave. It's really good work!

Sorry for the long delay 🙏 . Thx for the reviews! I hope I addressed your suggestions correctly. PTAL. Thx!

[janiskemper]

thanks @johannesfrey ! I went another time over the details and found a few things.

[janiskemper]

thanks @johannesfrey! Do you think anything is missing right now? If not, I'd propose the following path:

• I will do a final review
• You squash and rebase
• Someone from our team will again do a functionality test (which I haven't done at all) that the actual behavior is as expected

[johannesfrey]

thanks @johannesfrey! Do you think anything is missing right now? If not, I'd propose the following path:

* I will do a final review

* You squash and rebase

* Someone from our team will again do a functionality test (which I haven't done at all) that the actual behavior is as expected

That sounds awesome. Thx!
One thing that would be great to take a look at is my (probably too naive) way of testing the feature in controllers/hetznercluster_controller_test.go. There seems to be a data race, especially in the first test, where the cluster should attach to the previously created network. Most of the time it succeeds but there are cases where the reconciler errors that the requested network cannot be found while passing in the id. I'm struggling to see why this happens because the line of execution should look like this (ginkgo running serially):
create network with fake client -> check that there is no error -> add the id to the hetznercluster spec -> trigger a create of the hetznercluster -> wait until the hetznercluster ist ready and has the correct network condition and status

The reconciler should then use its internal client (which should be the shared fake one from before) to find the network. But it cannot find it, so there must be something in the line that deleted it or there is some race when using the fake client and probably the usage of the mutexes in there?! I tried some variations of changing the locks in there, but to no avail. So wasn't able to really deflake the test. So, would be really cool if you could take another look there. And if the test makes more harm than that it's helping, we could also think of removing/chaning it. WDYT?

[janiskemper]

mmh that's an important observation, thanks @johannesfrey. We will have a look. I'm not able to see anything in the code right now.