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

cinder-csi: consider using ClusterFirstWithHostNet DNSPolicy #2574

Closed
rptaylor opened this issue Apr 16, 2024 · 2 comments
Closed

cinder-csi: consider using ClusterFirstWithHostNet DNSPolicy #2574

rptaylor opened this issue Apr 16, 2024 · 2 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@rptaylor
Copy link
Contributor

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature

What happened:
Cinder CSI is using ClusterFirst DNSPolicy, but also appears to use hostNetwork.
Following up from #1387 (comment) , it seems like using ClusterFirstWithHostNet could be better but it's not entirely clear to me. FYI @jichenjc

Anything else we need to know?:
See https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy

Environment:

  • openstack-cloud-controller-manager(or other related binary) version:
  • OpenStack version:
  • Others:
@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 16, 2024
@dulek
Copy link
Contributor

dulek commented Apr 23, 2024

Seems like the chart has this configurable [1] and the default is in fact ClusterFirstWithHostNet [2]. This got fixed in #2483. What am I missing?

[1]

dnsPolicy: {{ .Values.csi.plugin.nodePlugin.dnsPolicy }}

[2]
dnsPolicy: ClusterFirstWithHostNet

@rptaylor
Copy link
Contributor Author

Oh, good to see it was already discussed. I guess the recent comment #1387 (comment) mislead us then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants