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" <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/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-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
