[WIP] [DO_NOT_MERGE] Test lb name

[willie-yao]

What type of PR is this?
Testing failure https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api-provider-azure#capz-periodic-apiversion-upgrade-main

What this PR does / why we need it:

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:

• cherry-pick candidate

TODOs:

• squashed commits
• includes documentation
• adds unit tests

Release note:

NONE

[willie-yao]

/test ls

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from willie-yao. For more information see the Kubernetes Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[k8s-ci-robot]

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

• /test pull-cluster-api-provider-azure-apiversion-upgrade
• /test pull-cluster-api-provider-azure-build
• /test pull-cluster-api-provider-azure-ci-entrypoint
• /test pull-cluster-api-provider-azure-e2e
• /test pull-cluster-api-provider-azure-e2e-aks
• /test pull-cluster-api-provider-azure-test
• /test pull-cluster-api-provider-azure-verify

The following commands are available to trigger optional jobs:

• /test pull-cluster-api-provider-azure-apidiff
• /test pull-cluster-api-provider-azure-capi-e2e
• /test pull-cluster-api-provider-azure-conformance
• /test pull-cluster-api-provider-azure-conformance-custom-builds
• /test pull-cluster-api-provider-azure-conformance-dual-stack-with-ci-artifacts
• /test pull-cluster-api-provider-azure-conformance-ipv6-with-ci-artifacts
• /test pull-cluster-api-provider-azure-conformance-with-ci-artifacts
• /test pull-cluster-api-provider-azure-e2e-optional
• /test pull-cluster-api-provider-azure-e2e-workload-upgrade
• /test pull-cluster-api-provider-azure-load-test-custom-builds
• /test pull-cluster-api-provider-azure-windows-custom-builds
• /test pull-cluster-api-provider-azure-windows-with-ci-artifacts

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

• pull-cluster-api-provider-azure-apidiff
• pull-cluster-api-provider-azure-build
• pull-cluster-api-provider-azure-e2e
• pull-cluster-api-provider-azure-e2e-aks
• pull-cluster-api-provider-azure-test
• pull-cluster-api-provider-azure-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-sigs/prow repository.

[willie-yao]

/test pull-cluster-api-provider-azure-apiversion-upgrade

[codecov]

Codecov Report

Attention: Patch coverage is 62.50000% with 9 lines in your changes missing coverage. Please review.

Project coverage is 52.56%. Comparing base (8e06caf) to head (1160de8).
Report is 10 commits behind head on main.

Files with missing lines	Patch %	Lines
azure/scope/cluster.go	62.50%	7 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5293      +/-   ##
==========================================
- Coverage   52.57%   52.56%   -0.01%     
==========================================
  Files         272      272              
  Lines       29408    29425      +17     
==========================================
+ Hits        15462    15468       +6     
- Misses      13148    13157       +9     
- Partials      798      800       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[willie-yao]

/test pull-cluster-api-provider-azure-apiversion-upgrade

[nawazkh]

/test pull-cluster-api-provider-azure-apiversion-upgrade

[k8s-ci-robot]

@willie-yao: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-provider-azure-apiversion-upgrade	1160de8	link	true	/test pull-cluster-api-provider-azure-apiversion-upgrade

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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-sigs/prow repository. I understand the commands that are listed here.

[nawazkh]

E1121 04:22:09.340665       1 controller.go:324] "Reconciler error" err="failed to patch AzureCluster clusterctl-upgrade/clusterctl-upgrade-workload-irenzl: admission webhook \"validation.azurecluster.infrastructure.cluster.x-k8s.io\" denied the request: AzureCluster.infrastructure.cluster.x-k8s.io \"clusterctl-upgrade-workload-irenzl\" is invalid: spec.networkSpec.apiServerLB.name: Forbidden: API Server load balancer private IP should not be modified after AzureCluster creation." controller="azurecluster" controllerGroup="infrastructure.cluster.x-k8s.io" controllerKind="AzureCluster" AzureCluster="clusterctl-upgrade/clusterctl-upgrade-workload-irenzl" namespace="clusterctl-upgrade" name="clusterctl-upgrade-workload-irenzl" reconcileID="ca234f36-4064-4321-a7c1-cb14d842d3e6"

The above error if from the CAPZ controller log; Ref: recent upgrade test run

Thinking out loud:

• Hardwiring the default internal LB IP at cluster scope level doesnt seem to be the right approach. Especially when upgrading CAPZ versions.

• We either update the validation webhook(as Willie suggested), allow updates to frontendIPs of APIServer LB including private IPs.

  • Or the whole feature of creating internal LB should be put behind a feature flag as this is a breaking API breaking change.(Users have no way of opting out of creation of internal LB)

  What are your thoughts ?

[willie-yao]

One more thing: At the very least we need to check if apiServerInternalLBIP.PrivateIPAddress exists. If not, we skip setting frontendIPConfigs for the internalLB so this unblocks users who don't want a frontend ip for their internal lb. Or yeah like you said this should probably be a feature flag so we're not forcing the creation of an internal lb to people who don't want one.

[k8s-ci-robot]

PR needs rebase.

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-sigs/prow repository.

[willie-yao]

/close

[k8s-ci-robot]

@willie-yao: Closed this PR.

In response to this:

/close

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-sigs/prow repository.