Hi Tim, > IMO, you've got to be clear what the underlying information model that > puppet / facter supports is. In particular, if you simply say that the > facts are the data reported by the underlying tools, then you've got > zero abstraction of the model and it's 'an exercise for the user to > handle the differences between platforms.
I agree with you there needs to be clarity as to what standard/ information model is to be supported. To me there are two standards in operation here and an assumption being made. At this time to me DNS is assumed to be the only valid overarching "directory service" and "naming standard". POSIX the underlying Unix standard makes no such assumptions as to which overarching directory service or naming standard will be in operation. Hypothetically should a site admin choose to support WINS (heaven forbid) or some other standard, POSIX which has portability in mind caters for that. I concede DNS is the most widely used directory standard, naming service around but it is still an assumption. If DNS is the only valid naming standard that can apply to the hostname is to the exclusion of IEEE Std 1003.1-2008 (POSIX:2008) which to my knowledge doesn't comment on the restriction of character sets for hostnames, so currently puppet at this point in time can not report on a POSIX compliant hostname from the Kernel if it contains a period (.). (NB if puppet were to support this I'm suggesting a different fact so as to not interfer with current operations) http://pubs.opengroup.org/onlinepubs/9699919799/functions/uname.html If to support multiplatform (IE Windows), one must allow for and consider other valid directory naming standards and directory services and or the underlying OS standard. > Alternatively, you can > define a canonical ontology and how the different tools map onto that > ontology. Even with such an ontology, you probably need to include > platform specific types in the data model. > fwiw, I'm also a big fan of encouraging best practice in the use of > the tools, so in this instance, the teaching/documentation would show > how to avoid naming pitfalls introduced by differences in standards > and how to remediate an environment that's fallen into such a trap. > Otherwise, the tools get bogged down in handling nasty > inconsistencies, which are impossible to cope with cleanly in code as > they depend on implicit or explicit customer organisational policies - > and the tool gets blamed for any shortfalls, while the organisation > keeps digging itself deeper into the trap. I agree with promoting best practice, however which standard(s) is/are to be supported on a given platform should be taken into account. -- 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.
