Open Stack

Hi Stephen,

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. A bit confusing is domain part of the 
hostname (novalocal), which derived from Openstack-wide deprecated-now 
parameter "dhcp_domain":

$ curl http://169.254.169.254/latest/meta-data/hostname
jex-n1.novalocal

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 in metadata, it will not break backward compatibility with 
cloud-init but reduce bustle upon initial VM configuration :)

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.

Thank you.

On 9/8/17 12:12 PM, Stephen Finucane wrote:
> [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] https://bugs.launchpad.net/nova/+bug/1698010
> [2] https://review.openstack.org/#/c/395683/
> [3] https://review.openstack.org/#/c/480616/
> [4] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121948.ht
> ml
> [5] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121794.ht
> ml
> [6] http://lists.openstack.org/pipermail/openstack-dev/2017-September/121877.ht
> ml
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
Volodymyr Litovka
   "Vision without Execution is Hallucination." -- Thomas Edison

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170922/2bb7c84e/attachment.html>