settingsLogin | Registersettings

[Openstack-operators] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?

0 votes

[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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
asked Sep 25, 2017 in openstack-operators by Stephen_Finucane (1,620 points)   2

4 Responses

0 votes

I rely on cloud-init to set my hostnames.

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.

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.

So, please don't take this away.

On Fri, Sep 8, 2017 at 2:12 AM, Stephen Finucane sfinucan@redhat.com
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 8, 2017 by jpenick_at_gmail.com (860 points)  
0 votes

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
"dnsname" 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 22, 2017 by Volodymyr_Litovka (1,100 points)   1 6 8
0 votes

On 9/22/2017 10:02 AM, Volodymyr Litovka wrote:
And another topic, in Neutron, regarding domainname. Any DHCP-server,
created by Neutron, will return "domain" derived from system-wide
"dnsname" 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.

Per:

https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/internal-dns-resolution.html

https://developer.openstack.org/api-ref/network/v2/index.html#dns-integration

I thought this was all possible since Mitaka such that you could
configure neutron and designate to put a DNS domain on a network.

That's what Stephen was talking about in the original email, was should
we use that, if available, rather than the dhcp_domain option in nova.

I think this came up a bit last week in Denver at the PTG, and there was
some consensus around doing something like:

  1. For a new instance, if the neutron network has a dns_domain set, use
    it. I'm not totally sure how we tell from the metadata API if it's a new
    instance or not, except when we're building the config drive, but that
    could be sorted out.
  2. Otherwise use the dhcp_domain config option in nova.

--

Thanks,

Matt


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 22, 2017 by mriedemos_at_gmail.c (15,720 points)   2 4 5
0 votes

Hi Matt,

On 9/22/17 7:10 PM, Matt Riedemann wrote:

while this approach is ok in general, some comments from my side -

  1. For a new instance, if the neutron network has a dns_domain set,
    use it. I'm not totally sure how we tell from the metadata API if it's
    a new instance or not, except when we're building the config drive,
    but that could be sorted out.
    In some scenarios, ports can be created for VM but be detached until
    "right" time. For example, at the moment Nova don't reflect Neutron's
    port admin state to VM (long time was going to, but thanks to this
    discussion just filled a bug
    https://bugs.launchpad.net/nova/+bug/1719261 ). So, if you need VM with
    predefined port roles (with corresponding iptables rules), but, for some
    reasons, these ports should be DOWN, you need:
  • create them before VM will be created
  • pass their MAC addresses to VM in order to create corresponding udev
    naming rules and subsequent configuration
  • but don't attach them

In such scenario, network with "dns_domain" parameter can be unavailable
to VM since there are no attached ports from this network at the VM
creation time.

And a second point: what I wanted to say is that "dns_domain" is a
property, which is available only when Designate is in use. While it can
be immanent property of network for use with dnsmasq's "--domain"
parameter, in order to get useful responces for DHCP "domain" queries.
Not too critical, but full integration with DNS don't always required
while simple DHCP functionality is enough.

  1. Otherwise use the dhcp_domain config option in nova.
    Crazy idea is to get customization right here - if instance's "name" is
    FQDN itself (e.g. myhost.some.domain.here) then:

- ignore "dhcp_domain" and pass "name" unchanged as hostname to VM
- but use "hostname"-part of name (e.g. myhost) to register VM in Openstack

Thank you.

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


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
responded Sep 25, 2017 by Volodymyr_Litovka (1,100 points)   1 6 8
...