MAAS

Bug #1087183
Comment #5

Comment 5 for bug 1087183

Revision history for this message

Scott Moser (smoser) wrote on 2013-05-01:

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.

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.