<div dir="ltr">I rely on cloud-init to set my hostnames.<div><br></div><div>I have a number of internal systems which rely on a machine knowing its own hostname. In particular, at least one of my configuration management systems requires that a host pass its fqdn to an API to fetch its CM data, so grabbing hostnames and configuring them outside of nova in a large scale environment is not going to work.</div><div><br></div><div>Another point, most CM systems don't define configuration data for individual hosts, but rather by a role based bucket or group. When you're booting 3000 nodes you don't want to have to define a CM profile for each one, nor do you want to have to ssh in to all of them and set the hostname.</div><div><br></div><div>So, please don't take this away.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 8, 2017 at 2:12 AM, Stephen Finucane <span dir="ltr"><<a href="mailto:sfinucan@redhat.com" target="_blank">sfinucan@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Re-posting (in edited from) from openstack-dev]<br>
<br>
Nova has a feature whereby it will provide instance host names that cloud-init<br>
can extract and use inside the guest, i.e. this won't happen without cloud-<br>
init. These host names are fully qualified domain names (FQDNs) based upon the<br>
instance name and local domain name. However, as noted in bug #1698010 [1], the<br>
domain name part of this is based up nova's 'dhcp_domain' option, which is a<br>
nova-network option that has been deprecated [2].<br>
<br>
My idea to fix this bug was to start consuming this information from neutron<br>
instead, via the . However, per the feedback in the (WIP) fix [3], this<br>
requires requires that the 'DNS Integration' extension works and will introduce<br>
a regression for users currently relying on the 'dhcp_domain' option. This<br>
suggests it might not be the best approach to take but, alas, I don't have any<br>
cleverer ones yet.<br>
<br>
My initial question to openstack-dev was "are FQDNs a valid thing to use as a<br>
hostname in a guest" and it seems they definitely are, even if they're not<br>
consistently used [4][5]. However, based on other comments [6], it seems there<br>
are alternative approaches and even openstack-infra don't use this<br>
functionality (preferring instead to configure hostnames using their<br>
orchestration software, if that's what nodepool could be seen as?). As a<br>
result, I have a new question: "should nova be in the business of providing<br>
this information (via cloud-init and the metadata service) at all"?<br>
<br>
I don't actually have any clever ideas regarding how we can solve this. As<br>
such, I'm open to any and all input.<br>
<br>
Cheers,<br>
Stephen<br>
<br>
[1] <a href="https://bugs.launchpad.net/nova/+bug/1698010" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>nova/+bug/1698010</a><br>
[2] <a href="https://review.openstack.org/#/c/395683/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/395683/</a><br>
[3] <a href="https://review.openstack.org/#/c/480616/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/480616/</a><br>
[4] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/121948.ht
ml" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>September/121948.ht<br>
ml</a><br>
[5] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/121794.ht
ml" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>September/121794.ht<br>
ml</a><br>
[6] <a href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/121877.ht
ml" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2017-<wbr>September/121877.ht<br>
ml</a><br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</blockquote></div><br></div>