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

APIServerLB DNS name resolution causes deploy failure on air-gapped systems #4975

Open
r4f4 opened this issue May 10, 2024 · 1 comment · May be fixed by #4976
Open

APIServerLB DNS name resolution causes deploy failure on air-gapped systems #4975

r4f4 opened this issue May 10, 2024 · 1 comment · May be fixed by #4976
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.

Comments

@r4f4
Copy link
Contributor

r4f4 commented May 10, 2024

/kind bug

What steps did you take and what happened:
After CAPA creates the APIServer Load Balancer and it gets a DNS name, CAPA waits for the DNS name to resolve before continuing the installation [1][2]. I think this check was never reconsidered when support for a secondary LB was added.

Now consider the scenario where a cluster is deployed on an air-gapped system. Trying to resolve the LB DNS name will never succeed .

[1] #1641
[2] #1651

What did you expect to happen:
Only check for DNS name resolution when the APIServer LB is public.

Anything else you would like to add:
Air-gapped installations are a requirement in C2S/SC2S secret regions.

Environment:

  • Cluster-api-provider-aws version: master
  • Kubernetes version: (use kubectl version): 1.29
  • OS (e.g. from /etc/os-release):
@k8s-ci-robot k8s-ci-robot added kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 10, 2024
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If CAPA/CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@r4f4 r4f4 linked a pull request May 10, 2024 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-priority needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants