[Re-posting (in edited from) from openstack-dev]
Nova has a feature whereby it will provide instance host names that cloud-init
can extract and use inside the guest, i.e. this won't happen without cloud-
init. These host names are fully qualified domain names (FQDNs) based upon the
instance name and local domain name. However, as noted in bug #1698010 , the
domain name part of this is based up nova's 'dhcp_domain' option, which is a
nova-network option that has been deprecated .
My idea to fix this bug was to start consuming this information from neutron
instead, via the . However, per the feedback in the (WIP) fix , this
requires requires that the 'DNS Integration' extension works and will introduce
a regression for users currently relying on the 'dhcp_domain' option. This
suggests it might not be the best approach to take but, alas, I don't have any
cleverer ones yet.
My initial question to openstack-dev was "are FQDNs a valid thing to use as a
hostname in a guest" and it seems they definitely are, even if they're not
consistently used . However, based on other comments , it seems there
are alternative approaches and even openstack-infra don't use this
functionality (preferring instead to configure hostnames using their
orchestration software, if that's what nodepool could be seen as?). As a
result, I have a new question: "should nova be in the business of providing
this information (via cloud-init and the metadata service) at all"?
I don't actually have any clever ideas regarding how we can solve this. As
such, I'm open to any and all input.
OpenStack-operators mailing list