Issue #11915 has been updated by Daniel Pittman.
So, bringing this together:
There seems to be a general feeling that additional syntax, in our syntax
focused DSL, is not good. Using a hash is generally the right path; so we end
up with expressions that look like this:
notice("hello from $facts[osrelease]")
if $facts[puppetversion] < 1.2 { … }
file { "example.conf": path => $facts[customfact] ? { … } }
We have some reasonably convincing use cases for the server facts, but mostly
related to other headaches in usability - people want it to make `file()` work
more like `template()`, for example, or people who want to do database queries
because we don't offer sufficient cross-machine communication capabilities.
We have some very reasonable use cases on the client, which are not radically
different in cause than the server ones.
We have an absolute case of confusion, in that `settings` are naturally assumed
to be the agent settings, and a different name for master settings is strongly
preferable. We should make that change, even if it is potentially breaking,
though an ideal implementation can detect and warn about the bad name being
used.
----------------------------------------
Feature #11915: Segregate client facts, server facts and ENC params in topscope
hashes
https://projects.puppetlabs.com/issues/11915#change-56307
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.
