Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✨ Bring your own network #1472

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

johannesfrey
Copy link
Contributor

@johannesfrey johannesfrey commented Aug 31, 2024

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

Copy link
Contributor

@janiskemper janiskemper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@guettli @batistein what's your opinion?

api/v1beta1/hetznercluster_webhook.go Show resolved Hide resolved
api/v1beta1/hetznercluster_webhook.go Show resolved Hide resolved
Copy link
Contributor

@janiskemper janiskemper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

controllers/hetznercluster_controller.go Outdated Show resolved Hide resolved

if network != nil {
if len(network.Subnets) > 1 {
return nil, fmt.Errorf("multiple subnets not allowed")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should not be an error, but we rather should set an appropriate condition on the HetznerCluster object, create an event, and return nil here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope I understood you correctly here. I set the NetworkReadyCondition to false in that case. Also what do you mean with "create an event"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johannesfrey didn't see your response here sorry. "record.Warnf()" would be appropriate here. that's actually something we should still add!

api/v1beta1/types.go Outdated Show resolved Hide resolved
@johannesfrey johannesfrey marked this pull request as ready for review November 13, 2024 17:08
@johannesfrey
Copy link
Contributor Author

johannesfrey commented Nov 13, 2024

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!

@syself-bot syself-bot bot added area/test Changes made in the test directory area/code Changes made in the code directory area/api Changes made in the api directory size/L Denotes a PR that changes 200-800 lines, ignoring generated files. labels Nov 13, 2024
Copy link
Contributor

@janiskemper janiskemper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

api/v1beta1/hetznercluster_webhook.go Outdated Show resolved Hide resolved
}
} else {
// If no ID is given check the other network settings for valid entries.
if r.Spec.HCloudNetwork.NetworkZone != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is supposed to happen if this is nil?

I just wanted to say that we should again avoid the nested if statements if possible and that we can do that here.

Currently, we don't handle the case where NetworkZone is nil at all. Shouldn't we though? Isn't that a problem?

Anyway, let's avoid the nested if statement and if you say we should, then let's handle the case where NetworkZone is nil

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should probably append an error when NetworkZone is nil. But still I'm struggling to see how to really circumvent the nested statements because the method's idea seems to be to aggregate all errors that might occur instead of returning early. An early return would then potentially miss other validation errors that might happen afterwards. But probably I'm just missing a detail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid the large code block for "NetworkZone != nil". However, I think you are right that this is not really possible, as we cannot just return at that point.

Therefore, I would say let's add a handling of "NetworkZone == nil" and otherwise don't change anything. Does that make sense to you?

}
}

if r.Spec.HCloudNetwork.CIDRBlock != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again here and below it should never be nil afaik. Should we return errors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aligns with the comment above. Do you mean return with an error here? Because in this method we only aggregate and return at the bottom?!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I mean with "returning errors" to "add them". Sorry for being not precise

api/v1beta1/hetznercluster_webhook.go Show resolved Hide resolved
api/v1beta1/hetznercluster_webhook.go Outdated Show resolved Hide resolved
api/v1beta1/hetznercluster_webhook.go Show resolved Hide resolved
api/v1beta1/hetznercluster_webhook.go Outdated Show resolved Hide resolved
api/v1beta1/types.go Outdated Show resolved Hide resolved
pkg/services/hcloud/network/network.go Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Changes made in the api directory area/code Changes made in the code directory area/test Changes made in the test directory size/L Denotes a PR that changes 200-800 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make it possible to use a pre-created private network
3 participants