On 2015-11-06 19:24, Francois Lafont wrote:
Hi,
I'm learning Puppet 4 and especially the Puppet 4 API for custom
functions and "data binding" in modules. Currently, my sources are:
-
http://puppet-on-the-edge.blogspot.fr/2015/01/puppet-40-data-in-modules-and..html
-
http://puppet-on-the-edge.blogspot.be/2015/02/puppet-40-data-in-modules-part-ii.html
-
https://github.com/puppetlabs/puppet-specifications/blob/master/language/func-api.md#function-api
But I have questions yet. ;)
Cool, you are an early user, we expect to add more to this, and the road
may be a bit bumpy at the beginning :-)
1. About the "data binding" in a modules, if I understand well the
`./mymodule/lib/puppet/functions/mymodule/data.rb` function replaces
completely the "params" pattern, so that the "params" pattern is
completely useless in a module using the Puppet 4 API. Is is correct?
It is an alternative to using the "params" pattern, yes. Now, since it
is possible to write the "mymodule::data" function in the puppet
language it should also be much easier and the code should look very
similar to the puppet logic for the "params" pattern.
(One more related tip is to take a look at the deep case match feature
when writing logic that have many if/then/else and nested such expressions).
2. Always about the "data binding" in a modules, is it correct to say
that the `data.rb` function replaces too the default values in the
declaration of a class? For instance with:
class mymodule (
$param1 = 'default1',
$param2 = 'default2',
) {
...
}
I can remove the default values in the class and put it in the `data.rb`
function. Is it correct?
Yes you can remove the defaults if you are sure you have values for them
in the data function - this because they will automatically get values.
A reason to keep them is for documentation purposes; they may help
increase the understanding of how to use the class.
3. In a module, if I have 2 public classes foo.pp and bar.pp, is it
possible to have 2 different `data.rb` functions, one for foo.pp and one
for bar.pp? Or maybe I can have only one `data.rb` function which
provides simultaneously the default values for foo.pp *and* bar.pp?
There is only one function that is called by the "data in modules"
framework. There is nothing stopping you from implementing it by calling
other functions and composing the result. Thus, modularizing the design.
Say something like:
function mymodule::data() {
mymodule::data::classa() + mymodule::data::classb()
}
function mymodule::data::classa() {
$prefix = "mymodule::data::classa"
{ "${prefix}::param1" => valuea1,
"${prefix}::param2" => valuea2,
}
}
function mymodule::data::classb() {
$prefix = "mymodule::data::classb"
{ "${prefix}::param1" => valueb }
}
4. In a custom function with the Puppet 4 API, in the `dispatch` method,
is it possible to provide more complex types than 'Array' or 'String',
for instance is it possible to provide types like "an array of strings"
or "an non empty array of non empty string"?
Yes, types have parameters for things like that; min, max lenghts,
contain data types. There is a rich type system.
(See the documentation, or my blog posts on the topic).
Array[String[1]] # array of non empty strings, array may be empty
Array[String] # array of strings (possibly empty string), -"-
Array[String[1], 1] # non empty array of non empty strings
Read more here:
http://puppet-on-the-edge.blogspot.se/2014/02/the-puppet-type-system-blog-posts.html
5. In a custom function with the Puppet 4 API, is it possible to get the
value of a variable in a module or of a fact? With the Puppet 3 API,
it's possible with `lookupvar('xxx')` but it works no longer with the
Puppet 4 API.
Access to the content of the calling scope is a bad idea for general
purpose code - it is far better to have pure functions (they process
what they are given as arguments and return a value).
It is possible to get either the closure_scope (the scope where the
function is defined), or the calling_scope. It is however required to
write a so called "system function", this because the API of the system
functions is more avanced, and that we may have reasons to change it in
the future. It is specified though (see language specification, an look
at the implementation of the more advanced functions (like the iterative
functions; each etc.)
Note that closure_scope is enough to lookup fully qualified variables
(and global variables). You invoke lookupvar on the closure_scope.
e.g. if you need a variable say $::osfamily
closure_scope.lookupvar('::osfamily')
If you really, really need the calling_scope, this shows you how:
https://github.com/puppetlabs/puppet-specifications/blob/master/language/func-api.md#calling-scope-support
6. In a custom function with Puppet 4 API, what is the difference between:
call_function(:fail, "Error, blabla blabla")
and
call_function("fail", "Error, blabla blabla") ?
You should use the string form 'fail', not the symbol form (:fail).
There is no gain using the symbol form since the search for the function
will need to split up the name based on namespace anyway.
I also noted that you posted questions on my blog - I responded there as
well:
http://puppet-on-the-edge.blogspot.se/2015/01/puppet-40-data-in-modules-and.html?showComment=1434066591043#c2269583057836628025
You asked if it was a good idea to call hiera from within a data
function. And my response there was:
"There is a new function named lookup that combines the behavior of all
hiera functions, it is also aware of data in modules. It is a bad idea
to call hiera from within a data function because your default data is
then no longer default and your module has a dependency on hiera.
Instead, you let users simply override values either in their
environment, or in their global hiera. When you lookup a key
"class_a::param1", if it is defined in hiera, it wins over the default
data provided in the module. You can use the "lookup" function though -
it always looks up using both hiera and data in modules. Say your
module_a depends on module_b, and you want some default values in
module_a to use data configured for module_b - then you can use the
lookup function in your module_a::data() function. It will get the
correct (possibly overridden value) in the user's configuration. (If you
use hiera to do the same, it will not ever lookup inside the "data in
modules/environment" since it is a singleton global implementation
across all environments and modules. Alternatively, if you module_a is
designed to work with module_b, and both are using data functions you
can call module_b's data function directly (as a function), and pick up
values that you use a defaults in your module_a. This way you get the
defaults from module_b (not overridden by data in the environment, nor
in hiera). This relies on module_b::data() function being considered
part of module_b's API."
I should have added that you need to be careful not to create circular
lookups (both with hiera and with data in modules).
That's all. ;)
Thanks in advance for your help.
Hope my answers will help you out - if not ask again...
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/mld72o%245ku%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
