Fix panic when no failure domain found

[alexander-demicev]

What type of PR is this? /kind bug

What this PR does / why we need it: We are using externally managed cluster infrastructure and nothing sets failure domain on cluster object, this makes controller panic when it's missing. I believe the controller should not panic here and fail in another place in this case.

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 #

Special notes for your reviewer:

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

TODOs:

• [ ] squashed commits
• [ ] includes documentation
• [ ] adds unit tests

Release note:

Fix panic when no failure domain found

[alexander-demicev]

@richardcase gcp cluster controller also tries to populate the failure domain field https://github.com/kubernetes-sigs/cluster-api-provider-gcp/blob/main/controllers/gcpcluster_controller.go#L179-L196 but regardless of that, if the payload is invalid it's better to fail somewhere on the GCP side than panic :)

[richardcase]

if the payload is invalid it's better to fail somewhere on the GCP side than panic :)

Agreed that a panic isn't good. I was trying to highlight that we should review our usage of Zone() more generally as it appears in some instances its not needed.

[cpanato]

@richardcase are you fine with this change?

[richardcase]

@cpanato - yes all good :+1:

Worth a try.....

/lgtm

[cpanato]

/test ls

[k8s-ci-robot]

@cpanato: The specified target(s) for /test were not found. The following commands are available to trigger required jobs:

• /test pull-cluster-api-provider-gcp-build
• /test pull-cluster-api-provider-gcp-e2e-test
• /test pull-cluster-api-provider-gcp-make
• /test pull-cluster-api-provider-gcp-test
• /test pull-cluster-api-provider-gcp-verify

The following commands are available to trigger optional jobs:

• /test pull-cluster-api-provider-gcp-apidiff
• /test pull-cluster-api-provider-gcp-capi-e2e
• /test pull-cluster-api-provider-gcp-conformance
• /test pull-cluster-api-provider-gcp-conformance-ci-artifacts
• /test pull-cluster-api-provider-gcp-coverage
• /test pull-cluster-api-provider-gcp-e2e-workload-upgrade

Use /test all to run the following jobs that were automatically triggered:

• pull-cluster-api-provider-gcp-apidiff
• pull-cluster-api-provider-gcp-build
• pull-cluster-api-provider-gcp-e2e-test
• pull-cluster-api-provider-gcp-make
• pull-cluster-api-provider-gcp-test
• pull-cluster-api-provider-gcp-verify

In response to this:

/test ls

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.

[cpanato]

/test pull-cluster-api-provider-gcp-capi-e2e /test pull-cluster-api-provider-gcp-conformance /test pull-cluster-api-provider-gcp-conformance-ci-artifacts /test pull-cluster-api-provider-gcp-e2e-workload-upgrade

[cpanato]

/hold for the non required tests

[JoelSpeed]

All tests have passed, any GCP maintainer happy to help and add the approve label?

[cpanato]

/unhold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alexander-demichev, cpanato

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:

• ~~OWNERS~~ [cpanato]

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