[Openstack-operators] [nova] [neutron] Should we continue providing FQDNs for instance hostnames?
doka.ua at gmx.com
Mon Sep 25 10:24:04 UTC 2017
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
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.
> 2. 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
"Vision without Execution is Hallucination." -- Thomas Edison
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators