MaaS cloud-init configuration specifies 'manage_etc_hosts: localhost'

I thought this was enabled to resolve an issue of using avahi with maas/juju?

Dave, see this bug about that:
bug 1086307
I suspect these are related.

The commit message on the revno (from 2012-10-03) that added manage_etc_hosts says:

--
          specify 'preserve_sources_list' to cloud-init in install preseed

          This moves the cloud-init/local-cloud-config out of the preseed explicitly
          and instead renders it in compose_cloud_init_preseed.

          We now put 2 items in this debconf escaped yaml, essentially feeding
          cloud-init this yaml:
            manage_etc_hosts: localhost
            preserve_source_list: true

--

Not sure this helps understand why it is there but at the same time I think it was added way after Avahi booting worked?

I can remove it, but I don't know enough about cloud-init to know what, if anything, it will break. So if someone can confirm it's ok I'll do it.

Some context. The situation is not at all simple. Here are some things to
think about:

a.) debian manual says what you see in /etc/hosts is actually *correct*
    http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution

    Ie, there *should* be an entry for 127.0.1.1 pointing to the system's
    hostname. This is done so that 'hostname' always resolves to
    something that can be reached (even in the absense of dns or
    networking).

b.) relying on dns provided by maas assumes that connection to maas's dhcp
    server is present even after installation. Ideally the instance once
    deployed could be detached from the management network entirely.

    This is very much a future maas feature, but it is something to think
    about.

c.) 'hostname --fqdn' as juju (and other things use) should not be used.
    From the man page of 'hostname'
     | If a machine has multiple network interfaces/addresses or is used
     | in a mobile environment, then it may either have multiple
     | FQDNs/domain names or none at all. Therefore avoid using
     | hostname --fqdn, hostname --domain and dnsdomain‐ name.
     ..
     | -f, --fqdn, --long
     | Display the FQDN (Fully Qualified Domain Name). A FQDN
     | consists of a short host name and the DNS domain name. Unless
     | you are using bind or NIS for host lookups you can change the
     | FQDN and the DNS domain name (which is part of the FQDN) in the
     | /etc/hosts file. See the warnings in section THE FQDN above, and
     | avoid using this option; use hostname --all-fqdns instead.

d.) There are really at least 2 different "hostnames" that matter
    "local-hostname":
      Maas has this concept, and provides 'local-hostname' to cloud-init
      in meta-data. Juju's MAAS provider assumes that it can reach
      machines via the 'local-hostname'. ('juju ssh service/0' for
      example).

      That assumption might not be true. While MAAS nodes (and thus the
      juju bootstrap node) are likely to be able to talk to each other via
      "local-hostname"s, it isn't true that other resources can.

    "public-hostname":
      In EC2, there is a 'public-hostname' that is resolves to the IPv4
      globally routeable address. This makes sense to use in some cases,
      but as it is something like ec2-54-234-174-100.compute-1.amazonaws.com
      Its probably not something that a user would say
      "Check out my new website at http://ec2-54-234-174-100.compute-1.amazonaws.com"

    "extrenally-provided-hostname":
      This is what the user would actually direct people to.

e.) for reference, 'manage_etc_hosts' first came into MAAS in revno 395
    (my commit) due to bug 972067
    I have a long winded bug report there
    https://bugs.launchpad.net/maas/+bug/972067

Mainly the above is just a brain dump, and a list of things that have to
be thought about.

Pertains to bug 1087183

About Scott's (a) point, the debian document says you should have host.domain in /etc/hosts if the system has a permanent address, and the host.domain line should be for that address, not 127.0.1.1:
"""
For a system with a permanent IP address, that permanent IP address should be used here instead of 127.0.1.1.

For a system with a permanent IP address and a fully qualified domain name (FQDN) provided by the Domain Name System (DNS), that canonical <host_name>.<domain_name> should be used instead of just <host_name>.
"""

Now, is a dhcp lease a permanent address? :) I think it's permanent enough for this scenario where MAAS is giving it out, as it even updates the DNS record.

Can someone mark the pyjuju task as won't fix?

> Now, is a dhcp lease a permanent address? :) I think it's permanent
> enough for this scenario where MAAS is giving it out, as it even
> updates the DNS record.

In this case, yes, I think it is permanent. MAAS promises to keep that
address for that node until it is released. DHCP is simply the
mechanism. Users are free to set this address statically in their node's
networking configuration.

We (Landscape team) had a meeting to discuss this with the server team (James Page, Scott Moser). Based on our discussion, there's consensus that it would be great if MAAS simply adhered to the Debian policy (see https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1087183/comments/7 )

That would mean that the permanent address would be written to /etc/hosts and the 127.0.1.1 wouldn't be written. That would be consistent and other applications would know what to expect.

Thanks!

I believe this fix in MAAS to be wrong :/

If we look in /etc/hosts after this fix landed there is no entry for the node's name

http://paste.ubuntu.com/8600284/

This breaks juju bootstrap:

http://paste.ubuntu.com/8600331/

Just did another bootstrap and it went without issue. Continuing to investigate...

So it seems that I was actually hitting bug 1383329 - because there is no entry in /etc/hosts anymore (fine) juju bootstrap is relying on DNS, which was flaky (as per bug).