Issue #11915 has been updated by Ryan Coleman.
Nigel Kersten wrote: > I'm not convinced it makes sense for facts to have a special syntax compared > to variables, but I can see the attraction. I'd love to see more people weigh > in on that point. When instructing new Puppet users, everyone is on-board with the variable syntax until we hit scoping. Then, the difference in their heads between variables they set and Facter facts becomes very grey and I'm usually forced to discuss how best to set Facter facts as students will either try or be confused by the idea of setting variables in top scope that match facts. I feel that giving Facter variables a different syntax makes it immediately clear that these are special and makes it immediately clear how users should reference facts they set in environment, facts.d, ruby code, whatever. It also allows someone to reference a top scope variable and know that they're never going to conflict with facts. In short, our users must understand less of how Puppet works and just use the software. ---------------------------------------- Feature #11915: Segregate client facts, server facts and ENC params in topscope hashes https://projects.puppetlabs.com/issues/11915#change-56013 Author: Brice Figureau Status: Needs Decision Priority: Normal Assignee: Randall Hansen Category: language Target version: Affected Puppet version: 2.7.9 Keywords: scope facts lookup hash Branch: Having to use $operatingsystem (and soon $::operatingsystem) in our manifests is: * confusing for new users * prone to name-clashing Those variables are really specific in Puppet because they come from the exterior. My proposal would be to move them to separate Puppet hashes of names: * `$facts` * `$server_facts` * `$parameters` So usage would be: <pre> ... firewall { "http": protocol => "TCP", src => $facts['ipaddress'] } file { "/etc/issue.net": content => "This host is in ${server_facts['environment']} environment" } ... </pre> We could also have some custom methods in the template wrappers so accessing facts in templates could be even easiers, like `facts['ipaddress']`. Of course to help migrate users, the first release would also put the facts/server facts and parameters in the node top scope (and issue a deprecation warning on lookup). -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
