On 2015-25-06 6:19, Francois Lafont wrote:
Hi,
Sorry again for my late answer.
On 17/06/2015 19:01, Henrik Lindberg wrote:
Functions in puppet are under <module>/functions/ and not under
<module>/lib/puppet/functions (where only ruby functions should live).
You do not have to change the bindings - it just called modulename::data() and
does not know or care if it is implemented in ruby or puppet.
Ok.
Clear, with puppet 4 you should be able to do most things (+ merges hashes, you
can concatenate arrays etc), the thing you cannot do is change variables, but
you can always use local scopes, use the iterative functions etc. This reduces
the need to have spaghetti logic and code that requires variables in the first
place - i.e. a more functional approach.
Ok, indeed with Puppet 4 it's more flexible but sometimes
I find it's more simple to use ruby code with mutable variables.
Ok, I understand well the "function" paradigm but if it's just in order
to *read* a fact, for instance to just read the 'lsbdistcodename' fact
and put it in a variable, is it really a bad idea? Ok I can add a parameter
to my function `fct(a, b, lsbdistcodename)` but if I can avoid this and just
have `fct(a, b)` and just get the 'lsbdistcodename' fact value in the
function (just for reading), where is the problem in this specific case?
That is not a problem, it is a global variable so does not depend on calling
context. In puppet:
function fct($a, $b) {
# get a fact
$facts[lsbdistcodename]
}
Ok, that's perfect.
What you want to avoid is creating dependencies - you want your modules to work
independently (just it, and its dependencies) without making assumptions that
certain data must be bound in hiera in a particular way across all environments.
As an example if you have a data function for modulea and want to give the
default value - you could do:
function mymodule::data() {
{ thekey => lookup('network::ip') }
}
Now you depend on 'network::ip' existing in hiera and having a value.
You could specify a default value if the key is missing. Now you have a default
value embedded in your module and if you need to change the default, you need
to find all such places to change it.
If you instead make modulea depend on a module 'networking' and let networking
contain the default values, you have specified something that is consistent in
terms of dependencies (no need to add a default to the lookup). If you want to
update the defaults for all usage of network::ip, create a new version of the
network module.
If you need to override that in one environment, add an environment::data()
function that returns the ip specific for that environment.
And, finaly, in a pinch, if you need to change something across all
environments Right Now (you need to do it right away and do not have time to
make the code changes/check in etc.), then change the network::ip key in hiera..
Err... I'm not sure to well understand. I will explain below with a real
example.
Ok, if I understand well with lookup function I allow overriding but
with module_b::data() this is not the case.
Not sure I understand what you are saying. The lookup function looks up the
value in hiera, environment, module
- the looked up key with the highest precedence wins (by default). So overrides
are possible. The data function
just specifies the data for what it is in (a module, or the environment)
If I understand well with lookup('foo::var') in the ::foo class, there will be
a look up:
- in hiera with the foo::var entry;
- in the environment with the environment::data() function (look up the value
of 'foo::var');
- in the foo module with the foo::data() function (look up the value of
'foo::var'.
Is it correct?
Yes, that is correct.
But what happens if I have just lookup('var') (ie the key is unqualified) in the
::foo class? Is there only a lookup in hiera? Because unqualified key seems to
be
not allowed in a *::data() function?
Correct, not allowed in a module. It can only bind to names in the
module's own namespace. In your environment you may bind any key.
Your environment can naturally also call functions in modules and
arrange those contributions in any way it likes.
If you want to modularize in a good way, and use the style of "theme" and functional
decomposition, then you want to avoid using hiera since it only looks up data across all
environments. You have to start including the environment in your hierarchy and have hiera
"dip into" environments to find data there.
You then only use hiera for installation specific overrides, and panic changes,
everything else is data in modules and environments.
In fact, I'm not sure to understand well. I take an real example.
I have a "network" module with the ::network class:
-------------------------------------
class network ( $interfaces, ) {
# Configure the file /etc/network/interfaces of a Debian host.
}
-------------------------------------
If I understand well I can set default values in the "data" function
of the "network" module and set the default like this (for instance):
-------------------------------------
network::interfaces = {
'eth0' => { 'method' => 'dhcp' }
}
-------------------------------------
And if I want to have another parameters for a specific node, I can put these
in the $fqdn.yaml of the node:
-------------------------------------
network::interfaces:
eth0:
method: 'static'
options:
address: '172.31.1.2'
netmask: '255.255.0.0'
gateway: '172.31.0.1'
eth1:
method: 'static'
options:
address: '10.0.0.2'
netmask: '255.0.0.0'
-------------------------------------
Is it correct?
yes. Your global hiera data wins over what is in the defaults for your
module. But for automatic data binding it wipes out the entire key since
it does not do deep merging and there is no way to control automatic
data binding with deep merge options.
You can do this if you do explicit lookups (use the lookup function).
But, now, imagine I want to improve the "network" module. Currently, for each
node which have an address in the "172.31.0.0/16" network, I will probably use
the same gateway ie 172.31.0.1 and I want to avoid it. So I put this in the
"common.yaml" file:
-------------------------------------
# The list of all my networks with some specific values such as
# the gateway (if it exists) or the dns etc.
network-inventory:
mgt-network:
address: '172.31.0.0/16'
gateway: '172.31.0.1'
dns: [ '172.31.0.1', '172.31.0.2' ]
web-network:
address: '192.168.0.0/24'
gateway: '192.168.0.1'
nfs-network:
address: '10.0.0.0/8'
-------------------------------------
And I want to just put something like this in the $fqdn.yaml files:
-------------------------------------
# For each node, I don't want to repeat the same gateway, the
# same netmask etc. 'default' will be replaced by the correct
# value in the corresponding network in "network-inventory".
network::interfaces:
eth0:
method: 'static'
options:
address: '172.31.1.2/16'
netmask: 'default'
gateway: 'default'
eth1:
method: 'static'
options:
address: '10.0.0.2/8'
netmask: 'default'
-------------------------------------
You can use additional functions in your environment to compute the
default gateway given the 'address' for the node. You can define that
function in a module, or in your environment. Here I used the 'network'
module (it may not make sense to you if your network module is generic,
and the ip addresses are specific to a site).
function network::default_gateway(String $ip) {
case $ip.split('[.]').map |$x| {$x+0} {
[172, 31, 0, Integer[0,16]] : { '172.31.0.1' }
# some other range : { 'n.n.n.n' }
# etc
default : { 'n.n.n.n' } # default if not matching any other range
}
}
This uses the 4.x deep matching ability in a case expression together
with the type system to match against a range after first having
converted an ip address as a string to an array of Integer values.
You can then call that with an address to get the gateway. Since you
know that you do not have circular lookups you can call that function
from your environment's data function.
In your environment data function:
function environment::data() {
{ network::interfaces = {
'eth0' => {
'method' => 'dhcp',
'options' => {
'gateway' => network::default_gateway(
lookup(network::interfaces::eth0::address))
}
}
}
}
And to "auto-complete" the 'default' values above, I have a
'::network::profile'
class in the 'network' module with something like that:
-------------------------------------
class network::profile {
$network_inventory = hiera('network-inventory')
$interfaces = hiera('network::interfaces')
class { '::network':
interfaces => network::complete_interfaces($interfaces, $network_inventory)
}
}
-------------------------------------
Almost, but don't use hiera calls if you want to also use the data bound
in the environment, and from modules - use lookup instead. You also want
to specify how a lookup should merge values - without merging, you will
need to re-specify everything "at the higher level", you only want the
"higher level" to override certain parts of a structure at a lower
level. Look at the merge options available in the
lookup function.
where 'network::complete_interfaces' is a "smart" function which replaces each
'default' value by the right value (the function will use the CIDR address to
find the good network in $network_inventory hash and to replace a 'default'
value correctly).
ok, so maybe you can call such a function instead of the function I
invented.
How can I do that if I want to modularize in a good way (with the "data
binding"),
and use the style of "theme" and functional decomposition etc.? If I understand
well,
it's not a good idea to have hiera lookups in a module and it's exactly that I
have
made in the example ::network::profile above. So how can I correctly do what I
want
in a way that respects the Puppet 4 patterns?
You have to consider what a module really knows; you can use anything
from any other module it depends on - such as functions or keys that
that module defines (i.e you know those functions and keys exist, they
can be documented, found, etc.). The bad thing to do is to just lookup
arbitrary keys that a user is expected to configure into their global hiera.
I think I would (I have not though this through), have a module with all
the defaults data bound in it, some defaults are computed via functions.
For some values where it is impossible to define a value, I would use a
default that the module's logic considers an error and inform the user,
"You must override the binding of the key ...."
(At some point I should write some blog posts about this, but I don't have time
at the moment).
The lack of time is an argument that I really can understand. ;)
No problem, your help has already been very useful for me.
I hope what I put together above makes sense and that you can make use
of that to come up with a composition that works for you. I am certainly
interested in what you come up with - or help with further questions.
Regards
- henrik
Thx Henrik.
François Lafont
--
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/mn7aaq%24fgk%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
