Open Stack

I rely on cloud-init to set my hostnames.

I have a number of internal systems which rely on a machine knowing its own
hostname. In particular, at least one of my configuration management
systems requires that a host pass its fqdn to an API to fetch its CM data,
so grabbing hostnames and configuring them outside of nova in a large scale
environment is not going to work.

Another point, most CM systems don't define configuration data for
individual hosts, but rather by a role based bucket or group. When you're
booting 3000 nodes you don't want to have to define a CM profile for each
one, nor do you want to have to ssh in to all of them and set the hostname.

So, please don't take this away.

On Fri, Sep 8, 2017 at 2:12 AM, Stephen Finucane <sfinucan at redhat.com>
wrote:

> [Re-posting (in edited from) from openstack-dev]
>
> 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].
>
> My idea to fix this bug was to start consuming this information from
> neutron
> instead, via the . However, per the feedback in the (WIP) fix [3], this
> requires requires that the 'DNS Integration' extension works and will
> introduce
> a regression for users currently relying on the 'dhcp_domain' option. This
> suggests it might not be the best approach to take but, alas, I don't have
> any
> cleverer ones yet.
>
> My initial question to openstack-dev was "are FQDNs a valid thing to use
> as a
> hostname in a guest" and it seems they definitely are, even if they're not
> consistently used [4][5]. However, based on other comments [6], it seems
> there
> are alternative approaches and even openstack-infra don't use this
> functionality (preferring instead to configure hostnames using their
> orchestration software, if that's what nodepool could be seen as?). As a
> result, I have a new question: "should nova be in the business of providing
> this information (via cloud-init and the metadata service) at all"?
>
> I don't actually have any clever ideas regarding how we can solve this. As
> such, I'm open to any and all input.
>
> Cheers,
> Stephen
>
> [1] https://bugs.launchpad.net/nova/+bug/1698010
> [2] https://review.openstack.org/#/c/395683/
> [3] https://review.openstack.org/#/c/480616/
> [4] http://lists.openstack.org/pipermail/openstack-dev/2017-
> September/121948.ht
> ml
> [5] http://lists.openstack.org/pipermail/openstack-dev/2017-
> September/121794.ht
> ml
> [6] http://lists.openstack.org/pipermail/openstack-dev/2017-
> September/121877.ht
> ml
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170908/a8391114/attachment.html>