Open Stack

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/48
> 0616/ 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.

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?

> 
> Stephen
> 
>>> [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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>