On Thursday, January 29, 2015 at 7:27:10 AM UTC-8, John Bollinger wrote: > > > DNS resolvers are irrelevant to the hosts file format. The hosts file is > not a *DNS* data source, even if resolver libraries happen to consult it, > too. In fact, the original objective of DNS was to altogether replace > hosts files. >
Mistaken word choice on my part. I meant hostname resolvers. > At the time the type was designed, however, hostname as namevar better > suited Puppet's capabilities and users' requirements, particularly with > respect to resource relationships. It would be rare for another resource > to depend on there being a name mapped to (say) address 10.11.12.13, but it > is reasonably common for another resource to depend on a name such as ' > myservice.my.com' being mapped to an address. Only with the advent of > the chain operators did Puppet gain the ability to declare relationships > other than via the target resource's namevar. > This makes sense. Indeed, having a composite namevar would make it less usable, which was something I was trying to reconcile from the beginning (c.f. my thoughts on and questions about resource aliasing). > I think your suggestion could be tweaked such that introduction of the > proposed new resource type didn't require *any* change to most existing > code. If, just as you suggested, the hypothetical new type, "Hostentry" / > "Hostname" / whatever, > > 1. autogenerated a corresponding Host resource, and > 2. created a 'before' relationship from itself to the corresponding > Host, > > then other resources could continue to 'require' Host resources just as > they do now. (I assert that other than as described above, no useful > purpose is served by a 'before' edge targeting a Host resource). > > Furthermore, with a bit of care in the type implementation, and perhaps a > new parameter or two for the Host resource, this scheme could also cause > duplicate resource errors to be properly thrown when a manually-declared > Host resource conflicts with a Hostentry resource. > > Avoiding a breaking change is an attractive feature of this strategy in > its own right, but it has the additional advantage that it does not require > hurrying to get an implementation into Puppet 4 (or waiting years for > Puppet 5). With P4 imminent, I am uncertain whether there is any chance at > this point to get an additional change/features into 4.0.0. > This is probably the best way forward. It might also be worth adding an additional dummy provider solely for the autogenerated host resources so that Puppet wouldn't try to use them to modify the hosts file. -- 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/c6d0d687-0242-48dd-b074-c139a59b2bbc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
