[jihyun-huh]

What this PR does / why we need it:

The OCCM Helm chart currently defaults to hostNetwork: true and dnsPolicy: ClusterFirstWithHostNet.
and this makes OpenStackAPI hostname resolution depend on cluster DNS, including when the API hostname is external to the cluster.

so during it's bootstraping, CoreDNS may be waiting for OCCM to initialize nodes and remove the node.cloudprovider.kubernetes.io/uninitialized taint. if OCCM needs CoreDNS to resolve its openstack api endpoint, neither component can make progress.

This PR is to change the chart default value and standalone manifests to dnsPolicy: ClusterFirst, with the default hostNetwork: true, and this restores the node DNS behavior that the chart had before #3097. (the node resolver must be able to resolve openstack api endpoints independently of cluster DNS)
With hostNetwork: false, ClusterFirst uses cluster DNS by default.

I found the same bootstrap previous failure was reported in #2611 and addressed by #2621.

also found Kubespray restored node DNS behavior in kubernetes-sigs/kubespray#11168 after encountering the same dependency cycle in 2024.

Which issue this PR fixes(if applicable):
Related to #2611 and #2621
fix #3258

Special notes for reviewers:

Release note:

[openstack-cloud-controller-manager] Change the Helm chart's default dnsPolicy and standalone manifests to ClusterFirst so OCCM uses node DNS during cluster bootstrap with hostNetwork enabled. The node resolver must resolve OpenStack API endpoints. Deployments requiring cluster DNS should explicitly set dnsPolicy to ClusterFirstWithHostNet with hostNetwork enabled. With hostNetwork disabled, ClusterFirst uses cluster DNS by default.

[kubernetes-prow]

[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 assign mandre for approval. For more information see the Code Review Process.

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

Details

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

[kubernetes-prow]

Hi @jihyun-huh. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

[winiciusallan]

/assign

[winiciusallan]

I would change this value back to ClusterFirst, because:

1. If someone is using this value as ClusterFirst, it wouldn't have much surprises when upgrading to a newer version;
2. ClusterFirst works unless HostNetwork is false. I would document what the implications are.

Don't know what others think.

[jihyun-huh]

thaks for your review, and that makes sense.
With hostNetwork: true and ClusterFirst also restores node DNS in the same way as the Default, so I’m happy with this approach.

[winiciusallan]

/lgtm

Can you please update the PR's description and the release-note to reflect ClusterFirst instead of Default?

[kubernetes-prow]

@winiciusallan: changing LGTM is restricted to collaborators

Details

In response to this:

/lgtm

Can you please update the PR's description and the release-note to reflect ClusterFirst instead of Default?

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.

[jihyun-huh]

@winiciusallan thanks, i updated the description!
also, could you give me /ok-to-test label pls?

[winiciusallan]

@winiciusallan thanks, i updated the description! also, could you give me /ok-to-test label pls?

I'm not an org member/reviewer, so I don't have that power. Sorry. We'd need someone else.

[jihyun-huh]

oh i see, @winiciusallan but also thanks for your review and feedback!

[IlanZuckerman]

Hi @jihyun-huh ! The rendering tests you added, cover the intended policy combinations well.
Do we have a bootstrap-level test or documented manual reproduction showing that OCCM resolves an external OpenStack endpoint before CoreDNS is schedulable? This is the behavior the change is protecting.

[jihyun-huh]

hi @IlanZuckerman, thanks for your comment! and also im thinking about adding bootstrap test for OCCM, especially using DNS server outside the Kubernetes cluster.
it would check that CoreDNS is blocked by the uninitialized taint, then confirm that OCCM resolves the endpoint, initializes the node and allows CoreDNS to start. would this approach address your concern?

if that so, i will mention you when i open the test PR

[IlanZuckerman]

hi @IlanZuckerman, thanks for your comment! and also im thinking about adding bootstrap test for OCCM, especially using DNS server outside the Kubernetes cluster. it would check that CoreDNS is blocked by the uninitialized taint, then confirm that OCCM resolves the endpoint, initializes the node and allows CoreDNS to start. would this approach address your concern?

if that so, i will mention you when i open the test PR

Yes, that addresses my concern well.
The key assertions would be: CoreDNS starts unschedulable because of the uninitialized taint.
The OpenStack endpoint hostname is resolvable through node DNS while CoreDNS is unavailable,
then OCCM initializes the Node/removes the taint, allowing CoreDNS to start.
Keeping the endpoint available only through the node resolver in the test setup would make the DNS-path distinction explicit.
A separate test PR sounds reasonable. please do mention me. Thanks!

/lgtm

[kubernetes-prow]

@IlanZuckerman: changing LGTM is restricted to collaborators

Details

In response to this:

hi @IlanZuckerman, thanks for your comment! and also im thinking about adding bootstrap test for OCCM, especially using DNS server outside the Kubernetes cluster. it would check that CoreDNS is blocked by the uninitialized taint, then confirm that OCCM resolves the endpoint, initializes the node and allows CoreDNS to start. would this approach address your concern?

if that so, i will mention you when i open the test PR

Yes, that addresses my concern well.
The key assertions would be: CoreDNS starts unschedulable because of the uninitialized taint.
The OpenStack endpoint hostname is resolvable through node DNS while CoreDNS is unavailable,
then OCCM initializes the Node/removes the taint, allowing CoreDNS to start.
Keeping the endpoint available only through the node resolver in the test setup would make the DNS-path distinction explicit.
A separate test PR sounds reasonable. please do mention me. Thanks!

/lgtm

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.

[stephenfin]

Hmm, looks like we've flip-flopped between these values a few times now (#2621, #3097). Hopefully this will be the last time we need to do so.

/cc @zetaab @mandre
/ok-to-test
/lgtm