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" <[email protected]> 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]. > 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
