My concern is with accurate modeling of existing state. For example:
[rnelson0@test ~]$ cat /etc/hosts
# HEADER: This file was autogenerated at Thu Jan 22 22:08:17 +0000 2015
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.
localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.
localdomain6
1.2.3.4 test
ffff::0001 test
[rnelson0@build profile]$ puppet resource host
host { 'localhost':
ensure => 'present',
host_aliases => ['localhost.localdomain', 'localhost4',
'localhost4.localdomain4'],
ip => '127.0.0.1',
target => '/etc/hosts',
}
host { 'test':
ensure => 'present',
ip => '1.2.3.4',
target => '/etc/hosts',
}
Puppet cannot accurately model the existing state, so it is difficult at
beast to enforce that state. There are so many edge cases that I feel it
may be impossible, but I don't think we've identified them all, much less
tested them. Regardless, such a simple hosts file should be enumerable as
an accurate model.
I do not have any good answers for this issue, but wanted to point out what
I think is a good guiding principle for resolving this. Perhaps picking a
single OS, a HostEntry type/provider can be built to try and accurately
model state, whether the namevar is the ip, hostname, or something else,
until we get it right. As a new type, there would be no deadline for Puppet
4 and hence it could be done right rather than making compromises again.
On Monday, January 26, 2015 at 8:06:33 PM UTC-5, Eli Young wrote:
>
> 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/b83b6570-49ff-4293-ae0a-08d88763237c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
