Consider Hetzner network set by cluster spec

[embik]

What does this PR do / Why do we need it:

#6588 introduced a network field for Hetzner on various levels (datacenter and cluster spec). The description suggests that the field on the cluster spec takes precedence over the datacenter field.

Unfortunately, it looks like the implementation back then did not consider the field on the cluster spec level for the generated MachineDeployments and only applied the datacenter-level value.

This can result in MachineDeployments failing to deploy if the datacenter value is not given or set to an empty string, or a mismatch from the network that is defined in CCM settings (as that does consider the cluster spec value):

kubermatic/pkg/resources/cloudcontroller/hetzner.go

Lines 79 to 82 in e234573

	network := data.Cluster().Spec.Cloud.Hetzner.Network
	if network == "" {
	network = data.DC().Spec.Hetzner.Network
	}

Does this PR close any issues?:
Fixes #8868

Special notes for your reviewer:

Documentation:

Does this PR introduce a user-facing change?:

If a network is set in the Hetzner cluster spec, it is now correctly applied to generated machines

Signed-off-by: Marvin Beckers marvin@kubermatic.com

[embik]

/cherry-pick release/v2.20

[kubermatic-bot]

@embik: once the present PR merges, I will cherry-pick it on top of release/v2.20 in a new PR and assign it to you.

In response to this:

/cherry-pick release/v2.20

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[embik]

/cherry-pick release/v2.19

[kubermatic-bot]

@embik: once the present PR merges, I will cherry-pick it on top of release/v2.19 in a new PR and assign it to you.

In response to this:

/cherry-pick release/v2.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[xrstf]

Oh thank god someone fixed this. I experienced some weirdness myself but never got around to investigating where I fucked up.

/approve

[kubermatic-bot]

LGTM label has been added.

Git tree hash: 49c031aecb701e8cb2508b11ada0c219a0aeac68

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: embik, xrstf

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/resources/OWNERS [embik,xrstf]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xrstf]

/retest

[xrstf]

/retest

[kubermatic-triage-bot]

/retest
This bot automatically retries jobs that failed/flaked on approved PRs

Review the full test history

Silence the bot with an /lgtm cancel or /hold comment for consistent failures.

[kubermatic-bot]

@embik: new pull request created: #8891

In response to this:

/cherry-pick release/v2.20

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kubermatic-bot]

@embik: new pull request created: #8892

In response to this:

/cherry-pick release/v2.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.