Open Stack

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" <sfinucan at 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].

> 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/