<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font face="SFNS Display">Hi Stephen,<br>
</font><br>
<font face="SFNS Display"><font face="SFNS Display">I think, it's
useful to have hostname in Nova's metadata - this provides some
initial information for cloud-init to configure newly created
VM, so I would not refuse this method.</font> A bit confusing is
domain part of the hostname (novalocal), which derived from </font><font
face="SFNS Display"><font face="SFNS Display">Openstack-wide
deprecated-now parameter "dhcp_domain</font>":<br>
<br>
$ curl <a class="moz-txt-link-freetext" href="http://169.254.169.254/latest/meta-data/hostname">http://169.254.169.254/latest/meta-data/hostname</a><br>
jex-n1.novalocal<br>
<br>
cloud-init qualify this as FQDN and prepare configuration
accordingly. Not too critical, but if there would be any way to
use user-defined domain part </font><font face="SFNS Display"><font
face="SFNS Display">in metadata, it will not break backward
compatibility with cloud-init but reduce bustle upon initial VM
configuration :)<br>
</font><br>
And another topic, in Neutron, regarding domainname. Any
DHCP-server, created by Neutron, will return "domain" derived from
system-wide "dns_name" parameter (defined in neutron.conf and
explicitly used in argument "--domain" of dnsmasq). There is no
way to customize this parameter on a per-network basis (parameter
"dns_domain" is in action only with Designate, no other ways to
use it). Again, it would be great if it will be possible to set
per-network domain name in order to deal with DHCP / DNS queries
from connected VMs.<br>
<br>
Thank you.<br>
</font><br>
<div class="moz-cite-prefix">On 9/8/17 12:12 PM, Stephen Finucane
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1504861937.28795.36.camel@redhat.com">
<pre wrap="">[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 [1], the
domain name part of this is based up nova's 'dhcp_domain' option, which is a
nova-network option that has been deprecated [2].
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 [3], 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 [4][5]. However, based on other comments [6], 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.
Cheers,
Stephen
[1] <a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/nova/+bug/1698010">https://bugs.launchpad.net/nova/+bug/1698010</a>
[2] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/395683/">https://review.openstack.org/#/c/395683/</a>
[3] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/480616/">https://review.openstack.org/#/c/480616/</a>
[4] <a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/121948.ht">http://lists.openstack.org/pipermail/openstack-dev/2017-September/121948.ht</a>
ml
[5] <a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/121794.ht">http://lists.openstack.org/pipermail/openstack-dev/2017-September/121794.ht</a>
ml
[6] <a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2017-September/121877.ht">http://lists.openstack.org/pipermail/openstack-dev/2017-September/121877.ht</a>
ml
_______________________________________________
OpenStack-operators mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison
</pre>
</body>
</html>