On Tue, May 31, 2011 at 14:04, Tim Coote <tim.coo...@googlemail.com> wrote: > Thanks, chaps. Pleased to hear that I'm not mad. The relationship > between IP addresses and hosts is non-trivial, especially when you > wrap in the MAC address concept. It's also asymmetrical in the sense > that the value seen from 'inside' a host may not relate to the value > used 'outside'.
Yeah. If you only ever dealt with the single-homed, single-address case (or maybe trivial NAT) it is easy to assume that there is "an" IP address for a host, but in the data center... not so much. :) > I've been through a lot of pain with this domain > model elsewhere (happy to provide references for those that are > interested, but no code, I'm afraid). There's also complexities if > one assumes that DNS resolves hostnames to IP addresses: it just > resolves names to IP addresses. Yeah; for a non-trivial number of cases this is the least wrong "do what I mean" answer, but it is absolutely not clear that the hostname and "the" IP address of a host are the same. I would only look to that if either I knew local convention assured it, or as a "less wrong" answer for this fact for compatibility. :) > I think that I'm going to ignore this issue for the moment as > something that just doesn't work yet. Yah. Better write your own fact, or resolution, to match local rules. Daniel > > Tim > > On May 31, 6:28 pm, Daniel Pittman <dan...@puppetlabs.com> wrote: >> On Tue, May 31, 2011 at 07:40, jcbollinger <john.bollin...@stjude.org> wrote: >> > On May 30, 3:10 pm, Tim Coote <tim.coo...@googlemail.com> wrote: >> >> Hullo >> >> I'm running facter 1.5.8 (fedora 13). I'm not very clear about what >> >> the variable ipaddress is supposed to represent. >> >> > I suggest you read the discussion at >> >http://groups.google.com/group/puppet-users/browse_thread/thread/f278..., >> > especially Daniel Pittman's response at the end. As Daniel observes, >> > *Facter* is not very clear about what that fact represents. >> >> >> I've read that it >> >> returns the ip address that's bound to the lowest alphabetic name of a >> >> network interface. That model seems a bit weird to me but that's >> >> probably because I'm just used to tools that return the set of IP >> >> addresses associated with the host, as seen from the host. >> >> > No, I think it's because you intuitively understand what Daniel wrote, >> > that Facter's ipaddress fact is not well-defined, and it is not very >> > meaningful in the general case. >> >> *nod* >> >> Nothing much has changed since way back when; we still have the same >> vague definition of what ipaddress means, which is "right" in the >> trivial case where you have only one IP address, and more or less >> wrong in any complex case. (We have a vague plan to try and be a bit >> more DWIM-ish by, indeed, respecting either the DNS IP for the current >> hostname, or the IP of the interface with the default route, when >> there is only one least-specific-route match. Patches welcome; it >> isn't super-high priority.) >> >> […] >> >> >> Facter is returning the IP v4 address on virbr0, which is neither what >> >> the documentation says, nor much use as I can see that it's likely to >> >> be the same on all hosts that have libvirt installed. There are no >> >> IPv6 addresses returned. >> >> I think the latest release has IPv6 support, which is distinct from >> the IPv4 facts. >> >> >> Am I seeing the expected behaviour for facter? Do I have to >> >> standardise how I name network interfaces and associate IP addresses >> >> to them to be able to deal with them all in a consistent, meaningful >> >> way (eg to pick out the IP that's used for backup, or the different IP >> >> addresses connected to the different edge switches)? >> >> I would strongly suggest you use something else. I did literally >> standardise on using the resolved IP from DNS, and made it a failure >> to compile when that failed to resolve. Your network might not >> support that, but I would suggest pretending the ipaddress fact just >> doesn't exist at all. >> >> Fixing the interface naming ... nah. Don't contort your network to >> support a stupid tool. Fix the stupid tool. >> >> (Incidentally, you should be able to replace the existing ipaddress >> fact with a better, higher priority version that does respect your >> needs, by putting a custom fact in place to override the shipped >> version. :) >> >> Daniel >> -- >> ⎋ Puppet Labs Developer –http://puppetlabs.com >> ✉ Daniel Pittman <dan...@puppetlabs.com> >> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 >> ♲ Made with 100 percent post-consumer electrons > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman <dan...@puppetlabs.com> ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
