On 09/06/2017 04:40 AM, Stephen Finucane wrote:
On Tue, 2017-09-05 at 12:30 -0500, Ben Nemec wrote:
On 09/04/2017 07:48 AM, Stephen Finucane wrote:
On Mon, 2017-09-04 at 11:51 +0000, Gary Kotton wrote:
On 9/4/17, 11:18 AM, "Stephen Finucane" <sfinu...@redhat.com> wrote:
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].
I've started work on a fix [3] that will allow us to retrieve this
information from neutron instead, uncoupling us from this legacy
option. However, some commentators have pointed out that this may not
necessarily be what we want to do: a FQDN is a hostname and domain
name, and using one as a hostname may not be that clever nor correct.
My networking fu isn't strong enough to deliver a verdict so I'm hoping
someone else can make my mind up for me: do we want to migrate this
feature to neutron, or do we want to stop using FQDN and just use
instance names?
Hi,
Your patch https://review.openstack.org/#/c/480616/ requires that neutron
expose the ‘DNS Integration’ extension be support by neutron and the
relevant networking plugin. If it does not then will be a regression and
things will not work.
In addition to this that is per network and not global so there will also
be a regression for running instances if nova is updated.
OK, so ultimately this isn't something we can rely on from neutron? Does
that mean we should abandon the idea of providing FQDN when using neutron?
Mores to the original point, is there any reason we would want to/should
use FQDN?
TripleO gets its FQDNs from this feature, which is how I noticed it was
still using the deprecated nova.conf value. So we need some way to
maintain that functionality. I'm not sure what would happen if
cloud-init stopped getting an FQDN - would it just set the hostname but
leave the domain as whatever was provided via DHCP? If so I think that
would be acceptable for us.
OK, and we do want to use a FQDN as the hostnames inside the guest? That's my
key question. Random ServerFault questions seems to suggest no clear answer to
this [1].
It's true that there is no definitive answer there, but I will point out
this: At least three different answers say something along the lines of
"I normally use just the shortname, but I discovered that [application]
requires the hostname to be an FQDN." The three examples I see are some
Oracle applications, FreeIPA, and Ganeti. I know we ran into issues
with non-FQDN hostnames in TripleO as well, probably for either Puppet
or RabbitMQ. I know they're both hostname-sensitive, I just don't
recall which was FQDN-sensitive too. That's why one of the first steps
of the undercloud install says "Ensure that there is a FQDN hostname set
and that the $HOSTNAME environment variable matches that value."
In that case we even went so far as to codify the hostname configuration
to make sure everything was FQDN and consistent. So I guess my vote
would be in favor of hostname as FQDN, which I realize doesn't simplify
this discussion at all. :-)
On the other hand, since it turns out this configuration option isn't
only used with nova-network maybe it should just be un-deprecated?
Perhaps with an update so that it is only used when Neutron doesn't
provide an FQDN?
You're correct in pointing out that it's not only used by nova-network, but
this seemed to be a mistake. The main issue I saw was that the nova-network
option is completely divorced from the neutron configuration and is static.
However, if we can't guarantee that this information will be available from
neutron, then perhaps a static configuration option is the only way to go? It's
quite the pickle.
Stephen
[1] https://serverfault.com/q/331936/
[1] https://bugs.launchpad.net/nova/+bug/1698010
[2] https://review.openstack.org/#/c/395683/
[3] https://review.openstack.org/#/c/480616/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
