Hi Ken [sorry for top-posting] I'm not a fan of supporting bad practice too strongly, it just becomes a stick with which to beat yourself with ;-)
I think that it would be better to show folk how to get a better model, and to point out that fqdns are not properties of hosts (they're properties of IP addresses). Indeed, there's a common antipattern of reuse of hostnames (ie the names that the boxes think they have). There are also some nasties where IP addresses on boxes are different from how they appear from the outside. I think that OWL's not a good target technology to use. If you put that much flexibility into the ontology that's supported, it's really hard to get useful work out of the tool (the user spends all their time trying to work out a model, which they're probably not skilled at). personally, I'd have a model for the technology and some documentation to show how this maps to different proprietary and de jure standards. The product should then honour this model, using whatever platform tools are available (and flagging where the tools are inconsistent/ incomplete, rather than trying to plug the holes.) Tim On Oct 6, 11:50 am, Ken Barber <[email protected]> wrote: > > 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'factif 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. > > Infactthere is a similar discussion for proper reporting for the > operatingsystemfactfor windows: > > http://projects.puppetlabs.com/issues/7643http://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 > operatingsystemfacton 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 thehostnameto 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.
