Open Stack

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

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/