FYI, code in Octavia that checks for the extensions you could borrow: https://github.com/openstack/octavia/blob/master/octavia/network/drivers/neutron/base.py#L49
On Mon, Sep 4, 2017 at 11:18 PM, Gary Kotton <gkot...@vmware.com> wrote: > > > 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 __________________________________________________________________________ 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
