@afritzler can you please try --hostname-override as a work around?

We tried that already. Didn't help though.

cloud providers are authoritative on node names, and --hostname-override does not affect a cloud provider-based node's name, because those names have to be deterministic in the cloud provider code that also runs on the apiserver and in the controller manager, not just in the kubelet (informed by --hostname-override)

see discussion in #58114 (comment) for more context

Same problem for us. Our metadata service reports the hostname as xyz.novalocal. and the name as xyz.

The kubelet aborts intial startup with:

flags.go:27] FLAG: --hostname-override="dev-payload-4dhlh"
...
server.go:494] Successfully initialized cloud provider: "openstack" from the config file: "/etc/kubernetes/openstack/openstack.config"
openstack_instances.go:41] openstack.Instances() called
 openstack_instances.go:48] Claiming to support Instances
...
server.go:731] cloud provider determined current node name to be dev-payload-4dhlh.novalocal
...
kubelet_node_status.go:271] Setting node annotation to enable volume controller attach/detach
openstack_instances.go:41] openstack.Instances() called
openstack_instances.go:48] Claiming to support Instances
kubelet.go:1349] Kubelet failed to get node info: failed to get external ID from cloud provider: instance not found
kubelet.service: Main process exited, code=exited, status=255/n/a
kubelet.service: Failed with result 'exit-code'.

The --hostname-override does work initially but get's ignored by CurrentNodeName here:
https://github.com/kubernetes/kubernetes/blob/v1.10.0/pkg/cloudprovider/providers/openstack/openstack_instances.go#L58

This just discards the hostname and picks up the FQDN from the metadata service. This behaviour is maybe intended and wasn't changed by the above mentioned patched. It worked by coincidence though 😄

I would like to avoid having to override the hostname anyway.

cloud providers are authoritative on node names, and --hostname-override does not affect a cloud provider-based node's name

Ok, fair enough. Given that #58502 is wrong. The node's name in Openstack is name and not hostname.

See the original bug #57765 (comment) for some context why the switch was done from name to something else. I agree that this something else should not have been hostname, as the reverse lookup (finding a server given a certain hostname) seems to be hard in the nova API.

Best next option, imho: using UUID instead.

A quick fix by @dims has just been merged here #61000. This should do the trick for now.

WDYT about @voelzmo idea of using UUIDs as the NodeName. Nasty output, but no worries about duplicate or invalide instance names.

/close