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

CAPO should set InternalDNS in status.Addresses #1689

Closed
mdbooth opened this issue Sep 27, 2023 · 1 comment · Fixed by #1715
Closed

CAPO should set InternalDNS in status.Addresses #1689

mdbooth opened this issue Sep 27, 2023 · 1 comment · Fixed by #1715
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@mdbooth
Copy link
Contributor

mdbooth commented Sep 27, 2023

/kind feature

Describe the solution you'd like
CAPO currently writes InternalIP and ExternalIP records to OpenStackMachine.Status.Addresses. However, it does not write InternalDNS. It should write an InternalDNS record containing the hostname of the machine.

This is useful information for other controllers consuming CAPI. Specifically, it is required by OpenShift's machine approver to automatically approve CSRs generated by a node for the target machine.

Anything else you would like to add:
InternalDNS should match the hostname as reported to the server by the metadata service. This is available in the OS-EXT-SRV-ATTR:hostname server attribute, but unfortunately this was admin-only until microversion 2.90. However, the way nova generates the hostname is relatively simple: it mangles the server name with sanitize_hostname, defined here: https://github.com/openstack/nova/blob/87d4807848bb9546c1fca972da2eb2eda13eb08d/nova/utils.py#L356-L389. It is probably a more pragmatic approach to re-implement this utility function in CAPO than bump to such a relatively recent microversion.

cc @stephenfin

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Sep 27, 2023
@mdbooth
Copy link
Contributor Author

mdbooth commented Oct 4, 2023

See the discussion in #1691 as to why that approach doesn't work. I think we should do what I described in #1691 (comment). That will most likely want to build on microversion support proposed in #1567.

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
2 participants