← Back to team overview

cloud-init team mailing list archive

Questions while I read: what to do about hostnames?


The "controller" setting - do we do anything, or not - I am told is:

# This will cause the set+update hostname module to not operate (if true)
preserve_hostname: false

So, this means true, do set+update. When I was younger using a double-negative was grounds for an automatic "F"ail for anything I was writing. Other than confuse - I do not see this statement do anything.

Let's skip down to set_hostname -- but first - ask ourselves what was a hostname when they coined the term and what is it now? I first recall the hostname as being the uucp (unix unix copy) node name - this predates TCPIP in UNIX by a few years. And even when TCPIP came around - a hostname was fairly fixed - every now and then a host admin would ftp the /etc/hosts from internic and be up to date again (yes, there was a world before DNS, and people could really communicate sending smoke signals :))

So, with regard to hostname - does it need to be unique? does it need to be associated with an IP address? If yes, to an IP address, which one, better which interface (e.g., node bound such as lo0) or external facing (e.g., eth0, en0). If the hostname is associated with an "external" interface is the hostname "static" (need to update /etc/hosts with a new IP address:hostname pair) or is it dynamic (both new IP address means new hostname aka hostname follows the IP address)

So, an idea I have - subject to change! would be to ignore "preserve_hostname" but look at "set_hostname"

a) I would see set_hostname for the actions I want taken during intial initializaton (i.e., during deployment)

b) I would look to update_hostname for behavior I want "configured" for "reboots" aka after initial deployment

set_hostname: false - nothing to do during deployment. What is, is.

set_hostname: true - hard to say "what the default behavior is to be", coming soon...

set_hostname: dhcp|source|xxxx - just think there may be more choices than dhcp or "datasource"

I see "dhcp" as pretty much the default Linux install behavior - certainly for net-installs, but also for DVD installs, once the system reboots. By source, i mean a "static" setup where both hostname and IP address/interface to bind it to are specified in the "data source" referenced during deployment - and now I wonder about how this may conflict/block update_hostname: settings

update_hostname: dhcp|static|source

Again, dhcp is what I call the "linux" way of seeing the world. I do not care what my hostname is, nether do I care what my IP address is. I have ways to make known where "I" am - hostname is irrevelant - maybe because I am a "client" only - I do not provide services to remote "hosts".

"static" is an alias for false aka do nothing, while "source" is "make sure it is reset, if needed, back to what the data source provided.

Anyway, I hope this is interesting for you. I am still thinking about what I would "fight for". I would like one of at least two things:

a) explain why the current setup/design is perfect

b) new ideas

c) maybe what I said, BUT (aka, yes, but)

Happy Holidays!


Follow ups