On 9/4/17, 3:47 PM, "Stephen Finucane" <step...@that.guru> 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?
[Gary] No, you can rely on it from Neutron – you just need to be aware that if 
the extension is supported then it can be used. If not then you should continue 
to use the existing configuration vaiable

 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?

[Gary] Yes, we should support this. Applications make use of this and hence the 
support
    
    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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to