On Monday, January 26, 2015 at 7:06:33 PM UTC-6, 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... > > As far as I can tell, it is a design characteristic of the current hosts file format that it associates each address with exactly one canonical name, and each canonical name with exactly one address. This is a bit ticklish, though, because there seems to be no canonical reference for the file format itself. Nevertheless, the Linux manpage for it says it has *one line* per IP address, and that "[f]or each host *a single line* should be present [...]" (emphasis added).
I am aware that some resolver implementations (including GNU's, documentation notwithstanding) seem to handle the same canonical name and/or the same alias appearing more than once in the hosts file. Nevertheless, Puppet's Host type must provide an abstraction that is applicable to all supported systems. There is a bit of room to fiddle with provider features, but you're contemplating a change much more fundamental than that could accommodate. Indeed, though the type's documentation merely says that a Host resource represents a "host entry", the longtime design demonstrates that it more specifically represents a mapping from a canonical hostname to properties of that hostname including a network address. It is implicit in the historic use of hostname alone as namevar that duplicate canonical names cannot be modeled. That these entries are typically recorded in /etc/hosts (on some systems) is in fact a function of the provider and of the 'target' property, so really the format and allowed usage of particular host files in particular contexts can be only weak guidance for whether the model is appropriate. Perhaps a better question is "what *should* a Host resource model"? With the (canonical) hostname as namevar it models properties of that name, but if the namevar were a composite of name and address then it would model properties of that *mapping*. Maybe that would indeed be better, but I don't think it can be taken as a given. > > 1. 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. > > Objection, Your Honor! Describing the issue as flawed parsing assumes that the files being parsed are correct, and that they are (intended to be) supported by Puppet, but the validity of both assertions is unclear. To be sure, Host files containing more than one record bearing the same canonical name do not comply with Puppet's model for host entries. It is unsurprising that Puppet does not handle such files well, but that could as easily be ascribed to invalid/incompatible files as to flawed parsing. > 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. > > You already covered resource modification and removal as a parsing issue. I am inclined to say "well, duh!" about removing a hostname having the effect of removing all its aliases -- I cannot imagine a person I would trust to write any manifest code being surprised by that -- but on the other hand, I rarely object to more documentation. > 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? > The proposed items (1) and (2) are natural for your characterization of the issue -- both that it is a problem that should be solved and the nature of that problem. As you observe, such a change could be very disruptive. Consider, however, the proposition that the issue you describe is a limitation of the Host resource that would be better documented and lived with than reworked as you describe. It would be worthwhile, I think, to at least fix Host removal so that it removes *every* entry bearing the Host's canonical name, but I don't think semver conflicts with making such a change in a minor (X.Y.0) release. People who need to manage configurations that Host cannot support must already do so via File resources (or not at all), so they are not affected anyway. Additionally, perhaps it would be better to deprecate the Host resource in favor of something different, maybe a "HostEntry", that is not burdened with the same limitations. As I already said, I have no objection to action item (3), which happens to be independent of everything else. Action item (4) does not appear to be an issue, supposing that the canonical hostname belonging to a Host resource continues to be exposed as a separate property. Inasmuch as 'name' would no longer be appropos for that property, perhaps it would be exposed as something like 'canonical_name'. In that case, you could establish resource relationships via collectors: Host<| canonical_name == 'db_server.my.com' |> -> Service['my_web_service'] What you could *not* do without knowing both hostname and address is establish a relationship with a specific Host resource among several for the same canonical name. John -- 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/ea15c44b-c7b0-4ed4-8bc9-f8a69de0f24a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
