As per PUP-3901 <https://tickets.puppetlabs.com/browse/PUP-3901>, the host
type has some serious issues. Major issues with the current design:
1. The namevar:
- It's currently the canonical hostname. This means that a hostname can
be the canonical representation for at most 1 IP address. This is a
problem if, for example, you want to provide both IPv4 and IPv6 addresses
for a hostname.
- Changing it to be the IP address would mean that an IP address
could have at most one canonical hostname associated with it. This is
less
of an issue, but still not ideal.
- Probably the best solution here is to change this to be both the IP
address and the canonical hostname (e.g. "1.2.3.4/example.com").
However...
2. Parsing is flawed:
- Multiple records with the same value for the namevar (currently the
canonical hostname) overlap and only one is registered. Modifying or
removing records that overlap behaves inconsistently and, in the case of
removal, requires multiple runs to achieve consistency. Examples in the
issue's description.
- Changing the namevar to be the IP address or both the IP address
and the canonical hostname could cause problems on Windows, where the
number of hostname aliases per record is limited. This could be resolved
by
having the provider split a resource into multiple records in the file if
the underlying system has alias count limits.
The other issues are all consequences of these two issues:
1. Inconsistent resource modification and removal (examples in the
issue's description) is a result of namevar collision.
2. Removal of a hostname causing removal of all the aliases is more of a
documentation issue than anything. So long as this is explicitly called out
as expected behavior, it's not a problem.
As such, my proposed changes to the host type are to:
1. Change the generated resource namevar (and, by extension, the alias
for specified resources) to use both the IP address and the canonical
hostname.
2. Fix parsing to handle cases where multiple records specify the same
namevar (which, after change #1, would be an IP address and canonical
hostname) by merging them into a single resource.
3. Update documentation to to indicate that the hostname aliases are not
first-class host items and that, when a hostname is removed, all aliases
are removed too. If the user wants to retain a hostname alias while
removing a hostname, they'll need to put it into a different host resource.
4. To allow manifests to set relationships to hosts without knowing
ahead of time what the IP address is, potentially provide resource aliases
with titles set to the hostname and all the hostname aliases.
Unfortunately, this runs into an issue when multiple host resources service
the same hostname; blindly making resource aliases would result in each
trying to alias to the same name, but conditionally aliasing based on if an
alias already exists would result in a relationship attaching to different
host resources depending on parse order. This is a problem that I'm not
sure how to solve.
Furthermore, since a resolution to this issue would almost definitely be a
breaking change, I recommend that we try to get it in for Puppet 4. If we
can figure out a solution for the problem in change #4, I can hammer out a
revised type, provider, tests, and documentation ASAP. Any thoughts?
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/b83498a4-a471-47e0-bfec-f66d4ce0ebc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
