Open Stack

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 <gkotton at vmware.com> wrote:
>
>
> On 9/4/17, 3:47 PM, "Stephen Finucane" <stephen at that.guru> 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?
> [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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev