Issue #11915 has been updated by Daniel Pittman.
Thinking about this, I have a few things to note: I can't see a good reason to expose either the server facts, or the server settings, to the manifest. These might make some sort of sense in a simple, one machine deployment today, but as we move to, eg, having dedicated compiler pools, or changing the data flows that lead from facts to catalogs, the "machine that compiled this" becomes a lot less ... predictable, or useful, or sensible to talk about in any way. It seems to me that we have chosen syntax as the approach of our DSL, which is awesome. It also seems that the single most important "variable" in the language are the client facts - almost every use of variables otherwise is to set configuration or move data about, or to mutate or reprocess facts to some other form. The former seems like it is better solved by way of Hiera, and data/model separation. The later seems like a lot of the demand will go away with structured facts. In both cases it seems a poor decision to treat the current - if critical - need to work around other shortfalls as a good basis for design going forward. I propose something different: * facts are dynamic, as they were in earlier versions. * facts have their own syntax: `%foo`, or `@foo`, or `&foo`, or `*foo` * facts are read-only This seems to have all the advantages and none of the drawbacks: * facts, the most important data, are immediately accessible with a minimum of ceremony. * facts are available everywhere. * facts are visually distinguished from variables. Especially the last point allows us to have different rules - variables are lexically scoped, but facts are dynamically scoped and global. It also makes it clearer to users what sort of data they are handling, and how. ---------------------------------------- Feature #11915: Segregate client facts, server facts and ENC params in topscope hashes https://projects.puppetlabs.com/issues/11915#change-54902 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.
