Issue #11915 has been updated by Henrik Lindberg.
Throwing one more option into the fire...
If access to facts should be via [] ("hash access"), it could be an operator on
a Fact type. e.g.
<pre>
Fact[osfamily]
</pre>
It can also be a function call, and when used with future parser's "inline"
call, it can be written
<pre>
osfamily.fact
</pre>
I could also imagine supporting both a notation that is guaranteed to get the
original fact (i.e. $fact[name], Fact[name], fact(name), name.fact, or
whatever) at the same time as facts are also available as variables (which
abide by the language scoping rules Du Joure. This would make it backwards
compatible, while those that want more strict behavior can use the longer form.
There is also an expectancy that the fact variables are always strings. The new
syntax could be smarter and provide proper types (String, Boolean, Number,
Array, Hash, etc.). Again, this to be backwards compatible.
In addition to this, there is also the discussion of trusted facts to take into
account. (There may be the need for the user to accept only a trusted fact, vs.
untrusted).
----------------------------------------
Feature #11915: Segregate client facts, server facts and ENC params in topscope
hashes
https://projects.puppetlabs.com/issues/11915#change-98474
* Author: Brice Figureau
* Status: Needs Decision
* Priority: Normal
* Assignee: J.D. Welch
* Category: language
* Target version:
* Affected Puppet version: 2.7.9
* Keywords: ux
* 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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
