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 puppet-dev+unsubscr...@googlegroups.com.
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.
