> I've had issues like this in a previous life (I was a founder of > Tideway Systems and we put a lot of effort into finding info from the > runtime environment and reasoning about what the returned info meant). > 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. 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.
So in this proposal we have 'hostname' which is defined as the shortname, and 'uname_nodename' which is the data derived from the system. One is cross-platform, the other is specific to POSIX systems with the uname data available. So if we created 'uname_nodename' this could be used internally be the 'hostname' fact if on a POSIX system that supports it. In OWL ontological terms this is not a 'owl:sameAs' but a derived relationship of some kind (?). > It is usually useful to separate out the data returned from > interrogation from how facter has interpreted it. Not least for > debugging and provenance purposes. Indeed. At the moment all facts are equal. I hope in the future name spacing can logically separate facts out - but I'm not sure enough metadata can be gleaned from namespaces - something to think about. I agree though - there is value in the separation. not only to solve the problem users are having here - but from a reporting/debugging perspective you can see more clearly what the system is really set to - not just how facter interprets it. In fact there is a similar discussion for proper reporting for the operatingsystem fact for windows: http://projects.puppetlabs.com/issues/7643 http://projects.puppetlabs.com/issues/7621 In #7643 we talk about exposing all the Win32_OperatingSystem WMI/CIM class vars ... and in #7621 we would simply use those for the operatingsystem fact on windows. Real value/contrived value layers has its value. > 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. It seems to me that most people have set the hostname to be the fqdn. And in a way (for right or wrong) this has become a pseudo-expectation. Not just for Puppet but for other things. I have worked with Doug and Dexter in places where they have done this - and have found myself working around issues in other places at times. Thanks for your informed input :-). ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
