Issue #11915 has been updated by R.I. Pienaar.
Daniel Pittman wrote:
> Nigel Kersten wrote:
> > I haven't seen use cases for exposing server facts to the manifests, but
> > there are certainly a few cases for the server settings.
>
> What are those, please? Several people have indicated that they are useful,
> and nobody can tell us what those cases are. If we can get the story from a
> user who wants to do that, we can absolutely support it, but without it ...
I've never found a use for them either. Here are some I've seen in #puppet
based on a search through my logs
* template() doesnt work like source which is what people want. So people
hack around this by referencing $settings::modulepath with file()
* scripts that interact with the exported resources database, someone wrote
the config file for that based on $settings::dbpassword etc
* while generating mcollective facts.yaml they use $settings::dynamicfacts to
exclude the variables that changes all the time
* they want to place files into the puppet config dir when managing puppet
master using puppet so $settings::configdir is a good variable to have
* testing infrastructure that check puppet code might run the manifests in a
odd place so people want to find $settings::manifestdir to base checks off.
Don't really get what this guy was doing, suspect its related to the first point
* someone wanted to know if pluginsync is enabled, presumably to figure out if
they can use some custom type.
* they want to configure the puppet.conf of the master using a template and
want to use these variables there...thats just a terrible idea
And thats every time that variable ever came up in #puppet since its release.
Nothing of this sounds like something we cant do without and most of them
sounds like people working around other deficiencies or design issues.
>
> > Daniel, can you elaborate on this?
> >
> > "facts are dynamic, as they were in earlier versions."
> > Even with the plans to remove dynamic scoping in Telly?
>
> Absolutely. I am specifically suggesting that facts and variables are
> different things, and can have different rules. Facts should have "dynamic"
> scope - @factname - that are available everywhere. Variables should have
> lexical scope.
>
> > 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.
>
> It is my view that facts should have a special syntax, and special behaviour,
> because they are the single most commonly accessed data in the system. They
> are universal things that most every part of the tree - manifests in modules
> you install, for example - want to reference.
I agree.
More though I think special syntax tells you when reading code that what is
required is a fact about the system and not someting else. This is important
information to know when evaluating code. Having special syntax means thats
obvious. It's important that the syntax we choose is also obvious in templates
and not too far from each other. $::foo vs scope.lookupvar("::foo") is an
example of where the disconnect is too big. $facts["foo"] vs @facts["foo"]
maybe not.
Having them in a hash aids discovery of information, there are legit reasons to
ask "what are all the facts for the node I am compiling" having a hash rather
than a series of variables that you cant iterate using something like keys()
means that's something thats doable vs just outright a pain.
We seem to have a number of special types of variables here:
* facts
* settings
* global variables such as those set in site.pp or provided by a ENC
* server facts
* node level variables
* variables passed in via paramters such as parameters to a define or class
If we wanted to call more than one of these out in some way to donate their
specialness I think we'd be better served by hash dynamics than just something
like *variable is a fact while %variable is a server settings. that would be
too confusing to new users and too alien for people coming from other systems.
Hashes are a universal concept even in bash scripts. I think it would be very
obvious for any newcomer to know what $facts["foo"] means once the concept of a
fact has been explained, but something like *foo will just forever increase the
confusion around the language
I'd specifically disagree with the statement that hash syntax is "awfully
heavy" especially in the context of that very same syntax being something many
people already know and would feel comfortable with. A specific example of
this is the $settings::foo syntax which is alien to everyone and people are
just not remembering how it works. We do have hashes in the language they're
widely used and understood and serves the purpose of storing all facts well.
Combine with this that data in hiera will be a hash using JSON hash syntax,
nested facts will be a hash using ruby hash syntax and retrievable on the
command line using something that approximates 'pp' or a hash or a simple JSON
dump. Mcollective is all about hashes and displays output in JSON
representation of a hash, and has tooling around
selecting/searching/interacting with hashes. I'd say that hashes are pretty
heavily entrenched in our world and will not go away, so rather than add more
types of hash like syntax - or finding ways to avoid them where they make sense
to people familiar with programming languages - we should just embrace hashes.
I'd be interested to see a main stream language that went with the conclusion
that hash like syntax is too much of a burdon and came up with an alternative
approach though. I would not want to see Puppet as the only or one of a very
small handful that went down that route though.
----------------------------------------
Feature #11915: Segregate client facts, server facts and ENC params in topscope
hashes
https://projects.puppetlabs.com/issues/11915#change-56004
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.
