Puppet 4: default value of a parameter in a module and dependency
2,371 views
Skip to first unread message
Francois Lafont
Nov 29, 2015, 11:09:20 PM11/29/15
to puppet...@googlegroups.com
Hi,
I'm using Puppet 4 and I'm wondering if this (see below) is possible.
I have 2 Puppet modules, moda and modb. We can imagine that theses modules
have just one class init.pp. The class ::moda has a parameter "param" with
the default value defined in the code of "./moda/functions/data.pp". The
module modb depends on the module moda (the dependency is indicated in
./modb/metadata.json) and the class ::modb have the parameter "param" too.
I would like to define the default value of the parameter ::modb::param
to ensure that it is equal to the value of ::moda::param, ie I would like
to have this:
a) If the value of ::moda::param is defined in hiera or in environment.conf
with "moda::param: xxxx", then the default value of ::modb::param is xxxx too.
b) If the value of ::moda::param is not defined at all (in hiera, in environment.conf
etc.), then the default value of ::modb::param is moda::data()['moda::param'].
Is there a proper way to do that with Puppet 4?
Thanks in advance for your help.
François Lafont
I'm using Puppet 4 and I'm wondering if this (see below) is possible.
I have 2 Puppet modules, moda and modb. We can imagine that theses modules
have just one class init.pp. The class ::moda has a parameter "param" with
the default value defined in the code of "./moda/functions/data.pp". The
module modb depends on the module moda (the dependency is indicated in
./modb/metadata.json) and the class ::modb have the parameter "param" too.
I would like to define the default value of the parameter ::modb::param
to ensure that it is equal to the value of ::moda::param, ie I would like
to have this:
a) If the value of ::moda::param is defined in hiera or in environment.conf
with "moda::param: xxxx", then the default value of ::modb::param is xxxx too.
b) If the value of ::moda::param is not defined at all (in hiera, in environment.conf
etc.), then the default value of ::modb::param is moda::data()['moda::param'].
Is there a proper way to do that with Puppet 4?
Thanks in advance for your help.
François Lafont
Martin Alfke
Nov 30, 2015, 5:28:24 AM11/30/15
to puppet...@googlegroups.com
Hi Francois,
On 30 Nov 2015, at 05:09, Francois Lafont <francois.l...@gmail.com> wrote:
> Hi,
>
> I'm using Puppet 4 and I'm wondering if this (see below) is possible.
>
> I have 2 Puppet modules, moda and modb. We can imagine that theses modules
> have just one class init.pp. The class ::moda has a parameter "param" with
> the default value defined in the code of "./moda/functions/data.pp". The
> module modb depends on the module moda (the dependency is indicated in
> ./modb/metadata.json) and the class ::modb have the parameter "param" too.
>
> I would like to define the default value of the parameter ::modb::param
> to ensure that it is equal to the value of ::moda::param, ie I would like
> to have this:
>
> a) If the value of ::moda::param is defined in hiera or in environment.conf
> with "moda::param: xxxx", then the default value of ::modb::param is xxxx too.
define modb with an explicit heira lookup and set a default:
class ‘modb’ (
param => hiera(‘moda::param’, ‘default’)
){
…
}
I am unsure on how to achieve this with data in modules.
>
> b) If the value of ::moda::param is not defined at all (in hiera, in environment.conf
> etc.), then the default value of ::modb::param is moda::data()['moda::param’].
same pattern, just set the default accordingly.
Best,
Martin
>
> Is there a proper way to do that with Puppet 4?
> Thanks in advance for your help.
>
> François Lafont
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/565BCBE4.9090008%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
On 30 Nov 2015, at 05:09, Francois Lafont <francois.l...@gmail.com> wrote:
> Hi,
>
> I'm using Puppet 4 and I'm wondering if this (see below) is possible.
>
> I have 2 Puppet modules, moda and modb. We can imagine that theses modules
> have just one class init.pp. The class ::moda has a parameter "param" with
> the default value defined in the code of "./moda/functions/data.pp". The
> module modb depends on the module moda (the dependency is indicated in
> ./modb/metadata.json) and the class ::modb have the parameter "param" too.
>
> I would like to define the default value of the parameter ::modb::param
> to ensure that it is equal to the value of ::moda::param, ie I would like
> to have this:
>
> a) If the value of ::moda::param is defined in hiera or in environment.conf
> with "moda::param: xxxx", then the default value of ::modb::param is xxxx too.
class ‘modb’ (
param => hiera(‘moda::param’, ‘default’)
){
…
}
I am unsure on how to achieve this with data in modules.
>
> b) If the value of ::moda::param is not defined at all (in hiera, in environment.conf
> etc.), then the default value of ::modb::param is moda::data()['moda::param’].
Best,
Martin
>
> Is there a proper way to do that with Puppet 4?
> Thanks in advance for your help.
>
> François Lafont
>
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/565BCBE4.9090008%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
jcbollinger
Nov 30, 2015, 10:09:39 AM11/30/15
to Puppet Users
On Sunday, November 29, 2015 at 10:09:20 PM UTC-6, François Lafont wrote:
Hi,
I'm using Puppet 4 and I'm wondering if this (see below) is possible.
I have 2 Puppet modules, moda and modb. We can imagine that theses modules
have just one class init.pp.
"init.pp" is the name of a manifest file, not of a class. Moreover, although it's poor form, such a manifest could contain definitions for more than one class. Moreover, in
The class ::moda has a parameter "param" with
the default value defined in the code of "./moda/functions/data.pp".
"./moda/functions/data.pp" appears to be the name of another manifest file. I suppose it's instead supposed to be a Ruby (.rb) file defining a custom function, and although I can speculate based on its name what it might do, the details matter, and you have not provided them.
The
module modb depends on the module moda (the dependency is indicated in
./modb/metadata.json) and the class ::modb have the parameter "param" too.
I would like to define the default value of the parameter ::modb::param
to ensure that it is equal to the value of ::moda::param, ie I would like
to have this:
a) If the value of ::moda::param is defined in hiera or in environment.conf
with "moda::param: xxxx", then the default value of ::modb::param is xxxx too.
b) If the value of ::moda::param is not defined at all (in hiera, in environment.conf
etc.), then the default value of ::modb::param is moda::data()['moda::param'].
$::moda::param has no value until and unless class ::moda is declared, and there is no reliable way to anticipate what value that parameter would have if its class were declared. (You might anticipate and emulate some of the ways in which a value could be bound to that parameter, but there are others that simply cannot be anticipated.) Once the class is declared, on the other hand, the only reasonable way to get the value of any of its parameters is to do so directly (i.e. as $::moda::param).
Is there a proper way to do that with Puppet 4?
I'm inclined to doubt that what you suggest is proper at all. It seems like an awfully tight coupling between modules. If class ::modb depends on class ::moda to be applied to to the target node (as opposed to depending only on data and maybe functions provided by module moda) then you can hack it together this way:
That's a variation on the "params class" pattern, which has been slowly falling out of favor. You could also interpose a genuine params class (modb::params) between classes ::moda and ::modb. In any event, this (anti?)pattern relies on a side effect of class inheritance to ensure that the parent class is evaluated before the child class, which in your case you need to ensure in order for one of moda's parameter values to be used directly as a default value of one of modb's parameters. This does give you increased exposure to the general Puppet constraint that if you ever use the resource-like syntax for a class declaration (i.e. of class ::moda) then that must be the first declaration of that class that is evaluated.
If you want to use $::moda::param in class ::modb in pretty much any other way than as a class parameter default, then you don't need and should not use class inheritance. For instance, this is an old-school approach that might be useful to you:
John
class modb inherits ::moda ($param = $::moda::param) {
# ...
}That's a variation on the "params class" pattern, which has been slowly falling out of favor. You could also interpose a genuine params class (modb::params) between classes ::moda and ::modb. In any event, this (anti?)pattern relies on a side effect of class inheritance to ensure that the parent class is evaluated before the child class, which in your case you need to ensure in order for one of moda's parameter values to be used directly as a default value of one of modb's parameters. This does give you increased exposure to the general Puppet constraint that if you ever use the resource-like syntax for a class declaration (i.e. of class ::moda) then that must be the first declaration of that class that is evaluated.
If you want to use $::moda::param in class ::modb in pretty much any other way than as a class parameter default, then you don't need and should not use class inheritance. For instance, this is an old-school approach that might be useful to you:
class modb inherits ::moda ($param = 'NOT GIVEN') {
include '::moda'
$real_param = $param ? {
'NOT GIVEN' => $::moda::param,
default => $param
}
# use $real_param in what follows ...
}John
Henrik Lindberg
Dec 1, 2015, 9:50:12 AM12/1/15
to puppet...@googlegroups.com
On 2015-30-11 16:09, jcbollinger wrote:
>
>
> On Sunday, November 29, 2015 at 10:09:20 PM UTC-6, François Lafont wrote:
>
> Hi,
>
> I'm using Puppet 4 and I'm wondering if this (see below) is possible.
>
> I have 2 Puppet modules, moda and modb. We can imagine that theses
> modules
> have just one class init.pp.
>
>
>
> "init.pp" is the name of a manifest file, not of a class. Moreover,
> although it's poor form, such a manifest could contain definitions for
> more than one class. Moreover, in
>
> The class ::moda has a parameter "param" with
> the default value defined in the code of "./moda/functions/data.pp".
>
>
>
> "./moda/functions/data.pp" appears to be the name of another manifest
> file. I suppose it's instead supposed to be a Ruby (.rb) file defining
> a custom function, and although I can speculate based on its name what
> it might do, the details matter, and you have not provided them.
>
In Puppet 4.x you can have functions written in the Puppet Language.
>
>
> On Sunday, November 29, 2015 at 10:09:20 PM UTC-6, François Lafont wrote:
>
> Hi,
>
> I'm using Puppet 4 and I'm wondering if this (see below) is possible.
>
> I have 2 Puppet modules, moda and modb. We can imagine that theses
> modules
> have just one class init.pp.
>
>
>
> "init.pp" is the name of a manifest file, not of a class. Moreover,
> although it's poor form, such a manifest could contain definitions for
> more than one class. Moreover, in
>
> The class ::moda has a parameter "param" with
> the default value defined in the code of "./moda/functions/data.pp".
>
>
>
> "./moda/functions/data.pp" appears to be the name of another manifest
> file. I suppose it's instead supposed to be a Ruby (.rb) file defining
> a custom function, and although I can speculate based on its name what
> it might do, the details matter, and you have not provided them.
>
Those reside under <module>/functions/<name>.pp
The data.pp is thus for a function called data. Such a function can be
used to provide data for a module - it is supposed to return a hash of
key => value mapping.
In addition to writing the function, a module can opt in to using this
data functions by adding a configuration in its module metadata.
This is all part of the 4.x data in modules / lookup feature.
In Puppet 4.3.0 we also added the ability to use hiera data in modules.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
Francois Lafont
Dec 1, 2015, 11:53:53 PM12/1/15
to puppet...@googlegroups.com
Hi,
On 30/11/2015 11:27, Martin Alfke wrote:
> define modb with an explicit heira lookup and set a default:
>
> class ‘modb’ (
> param => hiera(‘moda::param’, ‘default’)
> ){
> …
> }
>
> I am unsure on how to achieve this with data in modules.
Ah, indeed. In fact, with puppet 4, I think I can do this (not tested yet):
class modb (
$param,
){
...
}
And in data.pp
function modb::data () {
$param_if_set = lookup('moda::param', String, 'unique', undef)
if $param_if_set == undef {
$param = ::moda::data()['param']
} else {
$param = $param_if_se
};
{
modb::param => $param,
}
}
I will try a test...
François Lafont
On 30/11/2015 11:27, Martin Alfke wrote:
> define modb with an explicit heira lookup and set a default:
>
> class ‘modb’ (
> param => hiera(‘moda::param’, ‘default’)
> ){
> …
> }
>
> I am unsure on how to achieve this with data in modules.
class modb (
$param,
){
...
}
And in data.pp
function modb::data () {
$param_if_set = lookup('moda::param', String, 'unique', undef)
if $param_if_set == undef {
$param = ::moda::data()['param']
} else {
$param = $param_if_se
};
{
modb::param => $param,
}
}
I will try a test...
François Lafont
Francois Lafont
Dec 2, 2015, 12:21:25 AM12/2/15
to puppet...@googlegroups.com
Hi Henrik,
On 30/11/2015 19:12, Henrik Lindberg wrote:
> In addition to writing the function, a module can opt in to using this data functions by adding a configuration in its module metadata.
Err... can you explain a little? I don't see what it is.
> This is all part of the 4.x data in modules / lookup feature.
>
> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
Same remark: can you explain a little?
Do you know if this bug will be resolved soon?
https://tickets.puppetlabs.com/browse/PUP-5209
Because it seems to me that my goal in this thread is impossible with this bug, no?
Francois Lafont
On 30/11/2015 19:12, Henrik Lindberg wrote:
> In addition to writing the function, a module can opt in to using this data functions by adding a configuration in its module metadata.
> This is all part of the 4.x data in modules / lookup feature.
>
> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
Do you know if this bug will be resolved soon?
https://tickets.puppetlabs.com/browse/PUP-5209
Because it seems to me that my goal in this thread is impossible with this bug, no?
Francois Lafont
Francois Lafont
Dec 2, 2015, 12:26:15 AM12/2/15
to puppet...@googlegroups.com
On 30/11/2015 16:09, jcbollinger wrote:
> "init.pp" is the name of a manifest file, not of a class. Moreover,
> although it's poor form, such a manifest could contain definitions for more
> than one class.
Ok, sorry.
> "init.pp" is the name of a manifest file, not of a class. Moreover,
> although it's poor form, such a manifest could contain definitions for more
> than one class.
> "./moda/functions/data.pp" appears to be the name of another manifest
> file. I suppose it's instead supposed to be a Ruby (.rb) file defining a
> custom function,
With puppet 4, the "data philosophy" has changed.
François Lafont
jcbollinger
Dec 2, 2015, 8:53:00 AM12/2/15
to Puppet Users
On Tuesday, December 1, 2015 at 8:50:12 AM UTC-6, Henrik Lindberg wrote:
On 2015-30-11 16:09, jcbollinger wrote:
>
>
> On Sunday, November 29, 2015 at 10:09:20 PM UTC-6, François Lafont wrote:
>
> Hi,
>
> I'm using Puppet 4 and I'm wondering if this (see below) is possible.
>
> I have 2 Puppet modules, moda and modb. We can imagine that theses
> modules
> have just one class init.pp.
>
>
>
> "init.pp" is the name of a manifest file, not of a class. Moreover,
> although it's poor form, such a manifest could contain definitions for
> more than one class. Moreover, in
>
> The class ::moda has a parameter "param" with
> the default value defined in the code of "./moda/functions/data.pp".
>
>
>
> "./moda/functions/data.pp" appears to be the name of another manifest
> file. I suppose it's instead supposed to be a Ruby (.rb) file defining
> a custom function, and although I can speculate based on its name what
> it might do, the details matter, and you have not provided them.
>
In Puppet 4.x you can have functions written in the Puppet Language.
Those reside under <module>/functions/<name>.pp
Ah! This, I had somehow missed. Thanks, Henrik.
John
jcbollinger
Dec 2, 2015, 9:18:54 AM12/2/15
to Puppet Users
On Tuesday, December 1, 2015 at 11:26:15 PM UTC-6, François Lafont wrote:
No, no. You can see http://puppet-on-the-edge.blogspot.fr/2015/01/puppet-40-data-in-modules-and.html
With puppet 4, the "data philosophy" has changed.
I think "the data philosophy has changed" is a bit of an overreach. Two things relevant to the current discussion have happened:
If you conceive a module to be in a position to control or even to know whether and how a class from a different module is declared, then that's a strong signal that you should combine or refactor your modules. If you think one module has need for direct access to in-module data of a different module, then that is also a signal that you should combine or refactor.
John
- Puppet has adopted a data-in-modules mechanism into the core. This has been long desired, and was available -- in different form -- as a third-party module for Puppet 3. This, I already knew about.
- Puppet has added a mechanism to write custom functions in Puppet DSL, including such functions as underpin the data-in-modules mechanism. This, I had overlooked.
If you conceive a module to be in a position to control or even to know whether and how a class from a different module is declared, then that's a strong signal that you should combine or refactor your modules. If you think one module has need for direct access to in-module data of a different module, then that is also a signal that you should combine or refactor.
John
Henrik Lindberg
Dec 2, 2015, 5:55:56 PM12/2/15
to puppet...@googlegroups.com
On 2015-02-12 6:21, Francois Lafont wrote:
> Hi Henrik,
>
> On 30/11/2015 19:12, Henrik Lindberg wrote:
>
>> In addition to writing the function, a module can opt in to using this data functions by adding a configuration in its module metadata.
>
> Err... can you explain a little? I don't see what it is.
>
>> This is all part of the 4.x data in modules / lookup feature.
>>
>> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
>
> Same remark: can you explain a little?
Start here:
> Hi Henrik,
>
> On 30/11/2015 19:12, Henrik Lindberg wrote:
>
>> In addition to writing the function, a module can opt in to using this data functions by adding a configuration in its module metadata.
>
> Err... can you explain a little? I don't see what it is.
>
>> This is all part of the 4.x data in modules / lookup feature.
>>
>> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
>
> Same remark: can you explain a little?
https://docs.puppetlabs.com/puppet/4.3/reference/release_notes.html#new-feature-puppet-lookup
>
> Do you know if this bug will be resolved soon?
> https://tickets.puppetlabs.com/browse/PUP-5209
>
our board. We will take a look at it. Thanks for reporting back on the
ticket.
> Because it seems to me that my goal in this thread is impossible with this bug, no?
>
> Francois Lafont
>
Francois Lafont
Dec 4, 2015, 7:16:23 PM12/4/15
to puppet...@googlegroups.com
On 02/12/2015 23:55, Henrik Lindberg wrote:
>>> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
>>
>> Same remark: can you explain a little?
>
> Start here: https://docs.puppetlabs.com/puppet/4.3/reference/release_notes.html#new-feature-puppet-lookup
Thanks for the link Henrik, even if I'm not sure to have understood which is new in 4.3.0 concerning the lookup() function. ;)
>>> In Puppet 4.3.0 we also added the ability to use hiera data in modules.
>>
>> Same remark: can you explain a little?
>
> Start here: https://docs.puppetlabs.com/puppet/4.3/reference/release_notes.html#new-feature-puppet-lookup
>> Do you know if this bug will be resolved soon?
>> https://tickets.puppetlabs.com/browse/PUP-5209
>>
>
> We seemed to have dropped the ball on that one and it did not show up on our board. We will take a look at it. Thanks for reporting back on the ticket.
François Lafont
Francois Lafont
Dec 4, 2015, 8:23:44 PM12/4/15
to puppet...@googlegroups.com
Hi John,
Sorry for my late answer, right now I'm pretty busy. ;)
On 02/12/2015 15:18, jcbollinger wrote:
> On Tuesday, December 1, 2015 at 11:26:15 PM UTC-6, François Lafont wrote:
>
>
>> No, no. You can see
>> http://puppet-on-the-edge.blogspot.fr/2015/01/puppet-40-data-in-modules-and.html
>> With puppet 4, the "data philosophy" has changed.
>>
>>
> I think "the data philosophy has changed" is a bit of an overreach. Two
> things relevant to the current discussion have happened:
>
> 1. Puppet has adopted a data-in-modules mechanism into the core. This
Yes, you are absolutely right and your explanations show me that I was not
precise enough when I have described my question. Sorry for that. I will
try to fix it.
1. My question was in fact only about _public_ classes of my modules.
2. These classes are _always_ called via "require" or "include", never
with parameters. (The only case where I can call sometimes classes with
parameters is when a class in a module calls another private class of
the same module.)
So I fact my question is, for a node, the ENC will trigger this puppet code:
# Only "include" or "require".
include moda
include modb
include modc::fooc
include modc::barc
include modd::food
include modd::bard
include mode
etc...
and I would like to have the default value of ::modb::param equal to
the value of the parameter ::moda::param. And I think it's possible (if
1. and 2. are satisfied) with this code in ./modules/modc/functions/data.pp:
function modb::data {
# We assume that the type expected here is a non-empty string.
$param = lookup('moda::param', String[1], 'first')
# code...
{
...
modb::param => $param,
...
}
}
And mabe (but I'm not completely sure on this point), it could be a good
idea to put in ./modules/modb/metadata.json a dependency ("modb depends on
moda"). But I have lot of doubts on this point...?
John, are we agreed in these conditions?
> If you conceive a module to be in a position to control or even to know
> whether and how a class from a different module is declared, then that's a
> strong signal that you should combine or refactor your modules. If you
> think one module has need for direct access to in-module data of a
> different module, then that is also a signal that you should combine or
> refactor.
And in the conditions which I have described above, do you still think that
a refactor is needed?
According to me, 2 modules moda modb can be independent but sometimes it can
be relevant (and handy) that the default value of modb::param is equal to
the value of moda::param, no? For instance for the password shared between
a server and the clients ie "server::pwd" and "client::pwd".
Sorry again for my lack of details in my previous posts.
François Lafont
Sorry for my late answer, right now I'm pretty busy. ;)
On 02/12/2015 15:18, jcbollinger wrote:
> On Tuesday, December 1, 2015 at 11:26:15 PM UTC-6, François Lafont wrote:
>
>
>> No, no. You can see
>> http://puppet-on-the-edge.blogspot.fr/2015/01/puppet-40-data-in-modules-and.html
>> With puppet 4, the "data philosophy" has changed.
>>
>>
> I think "the data philosophy has changed" is a bit of an overreach. Two
> things relevant to the current discussion have happened:
>
> has been long desired, and was available -- in different form -- as a
> third-party module for Puppet 3. This, I already knew about.
> 2. Puppet has added a mechanism to write custom functions in Puppet DSL,
> third-party module for Puppet 3. This, I already knew about.
> including such functions as underpin the data-in-modules mechanism. This,
> I had overlooked.
>
> None of that impacts my primary thesis, however. It still is impossible to
> reliably predict what value a class parameter of an as-yet undeclared class
> would take if that class were declared later, by unspecified means. You
> can determine what value Puppet would choose via automated data binding,
> but even supposing that yields a value at all -- it does not need to do --
> you cannot, in general, be certain that automated data binding is the
> mechanism that ultimately will be used to set that parameter's value. That
> is, you cannot, in general, predict what value a class parameter *will *take.
> I had overlooked.
>
> None of that impacts my primary thesis, however. It still is impossible to
> reliably predict what value a class parameter of an as-yet undeclared class
> would take if that class were declared later, by unspecified means. You
> can determine what value Puppet would choose via automated data binding,
> but even supposing that yields a value at all -- it does not need to do --
> you cannot, in general, be certain that automated data binding is the
> mechanism that ultimately will be used to set that parameter's value. That
> If you are willing to ensure that the class is declared, however, then you
> can easily determine what value any of its parameters *does* take.
Yes, you are absolutely right and your explanations show me that I was not
precise enough when I have described my question. Sorry for that. I will
try to fix it.
1. My question was in fact only about _public_ classes of my modules.
2. These classes are _always_ called via "require" or "include", never
with parameters. (The only case where I can call sometimes classes with
parameters is when a class in a module calls another private class of
the same module.)
So I fact my question is, for a node, the ENC will trigger this puppet code:
# Only "include" or "require".
include moda
include modb
include modc::fooc
include modc::barc
include modd::food
include modd::bard
include mode
etc...
and I would like to have the default value of ::modb::param equal to
the value of the parameter ::moda::param. And I think it's possible (if
1. and 2. are satisfied) with this code in ./modules/modc/functions/data.pp:
function modb::data {
# We assume that the type expected here is a non-empty string.
$param = lookup('moda::param', String[1], 'first')
# code...
{
...
modb::param => $param,
...
}
}
And mabe (but I'm not completely sure on this point), it could be a good
idea to put in ./modules/modb/metadata.json a dependency ("modb depends on
moda"). But I have lot of doubts on this point...?
John, are we agreed in these conditions?
> If you conceive a module to be in a position to control or even to know
> whether and how a class from a different module is declared, then that's a
> strong signal that you should combine or refactor your modules. If you
> think one module has need for direct access to in-module data of a
> different module, then that is also a signal that you should combine or
> refactor.
a refactor is needed?
According to me, 2 modules moda modb can be independent but sometimes it can
be relevant (and handy) that the default value of modb::param is equal to
the value of moda::param, no? For instance for the password shared between
a server and the clients ie "server::pwd" and "client::pwd".
Sorry again for my lack of details in my previous posts.
François Lafont
jcbollinger
Dec 7, 2015, 11:18:11 AM12/7/15
to Puppet Users
I'm not sure where my agreement factors in. Your conditions are whatever they are, or at most what I can persuade you they should be.
I still maintain that you are contemplating an inappropriately tight coupling between your modules. You likely can come up with a list of restrictions sufficient to ensure that there is a method to determine what value a parameter of class ::moda would take in the event that that class were declared, other than actually declaring the class and checking what value it actually did take. You have not yet stipulated enough conditions for that, however: you would at least need to account also for the possibility of the value depending on Hiera interpolation tokens that in turn depend on the 'calling' class or module.
> If you conceive a module to be in a position to control or even to know
> whether and how a class from a different module is declared, then that's a
> strong signal that you should combine or refactor your modules. If you
> think one module has need for direct access to in-module data of a
> different module, then that is also a signal that you should combine or
> refactor.
And in the conditions which I have described above, do you still think that
a refactor is needed?
I think the specific conditions are irrelevant to the main thrust of my position. The fact that your code and data would need to comply with a relatively complex set of conditions for what you propose to be workable at all is one of my primary arguments. I predict that taking on such a set of extra requirements will cause you grief, more likely sooner than later, and I urge you to devise another way to accomplish your objective.
If you insist on proceeding in this general direction, however, then I'd suggest employing a variation on the Params Class pattern. Create a class ::moda::params and give it a parameter or ordinary class variable $::moda::params::param that will serve both as the (definite) initialization value for $::moda::param and as the default value for $::modb::param. This will require that $::moda::param be made an ordinary class variable instead of a class parameter, so that it can never take a value different from $::moda::params::param. It will also require that class ::modb inherit directly or indirectly from class ::moda::params. In Puppet 4, $::moda::params::param can receive its value in any way you see fit, including automated data binding (if you opt to make $::moda::params::param a class parameter), but you would create an evaluation-order dependency if every you used a resource-like declaration of it, either directly or via an ENC. Class ::moda::params would avoid declaring any resources so that declaring it (as classes ::moda and ::modb would both need to ensure happens) will not directly affect the target node's state.
If you're following closely you will observe that that solves the problem by adding a layer of indirection. You may also recognize that class inheritance across module boundaries is considered poor practice by many; this should be taken as further support for my argument that your proposed modules are too tightly coupled.
According to me, 2 modules moda modb can be independent but sometimes it can
be relevant (and handy) that the default value of modb::param is equal to
the value of moda::param, no? For instance for the password shared between
a server and the clients ie "server::pwd" and "client::pwd".
No. If a class of module modb depends on moda for a default value of one of its parameters, then for that very reason, modb is not independent of moda, neither conceptually nor code-wise. If you want two independent modules to share data, then they must each draw it from the same external source, rather than one drawing it from the other.
Drawing from the same source can be accomplished in a variety of ways. Indeed, my params class suggestion would be such a technique if the params class belonged to a module that was neither moda nor modb. You could also do it by defining an Hiera key that must be the ultimate source for the data, and ensuring that lookups for that key never fall back on module-specific data. There are other alternatives.
In fact, if what you wanted were what you actually just wrote -- "the default value of modb::param is equal to the value of moda::param" -- then although that establishes a dependency between modb and moda, it nevertheless could serve as a pattern for a shared data source. Specifically, you could then use ::moda itself as a params class for ::modb, or in some related way rely directly on $::moda::param for the data, as indeed I observed in an earlier message. But that's not what elsewhere you said you want, because you do not want to be obligated to declare ::moda to have a default value for $::modb::param. I say again: $::moda::param has no value -- neither in a conceptual sense nor in manifest evaluation sense -- until class ::moda has been declared.
John
Francois Lafont
Jan 4, 2016, 12:35:16 AM1/4/16
to puppet...@googlegroups.com
Hi,
Sorry for this late answer. I had time to think about this question of "design".
Ok, so I have thought about the "params" design in Puppet 4, and indeed
finally I'm wondering if something like that could be a good idea:
a) For a module moda, I use a class moda::params which has parameters and an
_empty_ body like this:
class moda::params (
String[1] $var1,
Array[String[1], 1] $var2,
String[1] $var3,
# etc.
) {
# The body of this class if completely empty!
}
This class above contains all parameters needed for the module moda.
b) Then I use ./moda/function/data.pp to set relevant default values for
the parameters of the class "moda::params":
function moda::data {
# Some code to chose relevant default values of $var1, $var2 etc.
$var1 = ...
$var1 = ...
# etc.
{
moda::params::var1 => $var1,
moda::params::var1 => $var2,
# etc.
}
}
b) And for any public class of moda, I create systematically a class without
parameter and I use the parameters of moda::params like this:
# moda::foo is a public class fo moda.
class moda::foo {
# Class without parameter, we use variables in moda::params instead.
require '::moda::params'
$var1 = ::moda::params::var1
$var2 = ::moda::params::var2
# etc.
# some code...
}
And now, if I have another module modb which depends on moda so that I
would like some default modb values are equal to some moda values, I can
create the module modb with the same principle described above _and_ :
a) I declare moda as dependency of modb in the metadata.json file of modb:
"dependencies": [
{"name":"puppetlabs-stdlib","version_requirement":">= 4.6.0"},
{"name":"me-moda","version_requirement":">= 0.1.0"}
]
}
b) and in the ./modb/function/data.pp of modb, I do something like that:
function modb::data {
require '::moda::params'
# I retrieve some variables of moda
$var1 = ::moda::params::var1
$var2 = ::moda::params::var2
{
# And for some variables of modb, I use variable of moda as default values.
modb::params::var1_modb => $var1,
modb::params::var2_modb => $var2,
modb::params::var3_modb => 'foo'
# etc.
}
}
Is this pattern "correct"? After thinking, it seems to me a good way to
handle data dependency between modules but I'm really not a puppet expert
and I really appreciate any remark from you John and/or from any other
puppet expert. ;)
Thanks in advance.
--
François Lafont
Sorry for this late answer. I had time to think about this question of "design".
finally I'm wondering if something like that could be a good idea:
a) For a module moda, I use a class moda::params which has parameters and an
_empty_ body like this:
class moda::params (
String[1] $var1,
Array[String[1], 1] $var2,
String[1] $var3,
# etc.
) {
# The body of this class if completely empty!
}
This class above contains all parameters needed for the module moda.
b) Then I use ./moda/function/data.pp to set relevant default values for
the parameters of the class "moda::params":
function moda::data {
# Some code to chose relevant default values of $var1, $var2 etc.
$var1 = ...
$var1 = ...
# etc.
{
moda::params::var1 => $var1,
moda::params::var1 => $var2,
# etc.
}
}
b) And for any public class of moda, I create systematically a class without
parameter and I use the parameters of moda::params like this:
# moda::foo is a public class fo moda.
class moda::foo {
# Class without parameter, we use variables in moda::params instead.
require '::moda::params'
$var1 = ::moda::params::var1
$var2 = ::moda::params::var2
# etc.
# some code...
}
And now, if I have another module modb which depends on moda so that I
would like some default modb values are equal to some moda values, I can
create the module modb with the same principle described above _and_ :
a) I declare moda as dependency of modb in the metadata.json file of modb:
"dependencies": [
{"name":"puppetlabs-stdlib","version_requirement":">= 4.6.0"},
{"name":"me-moda","version_requirement":">= 0.1.0"}
]
}
b) and in the ./modb/function/data.pp of modb, I do something like that:
function modb::data {
require '::moda::params'
# I retrieve some variables of moda
$var1 = ::moda::params::var1
$var2 = ::moda::params::var2
{
# And for some variables of modb, I use variable of moda as default values.
modb::params::var1_modb => $var1,
modb::params::var2_modb => $var2,
modb::params::var3_modb => 'foo'
# etc.
}
}
Is this pattern "correct"? After thinking, it seems to me a good way to
handle data dependency between modules but I'm really not a puppet expert
and I really appreciate any remark from you John and/or from any other
puppet expert. ;)
Thanks in advance.
--
François Lafont
jcbollinger
Jan 4, 2016, 11:01:13 AM1/4/16
to Puppet Users
On Sunday, January 3, 2016 at 11:35:16 PM UTC-6, Francois Lafont wrote:
Is this pattern "correct"? After thinking, it seems to me a good way to
handle data dependency between modules
Your revised idea appears workable. It establishes class moda::params as a shared data source, along the lines I suggested. It allows module moda to be customized, via class moda::params, and if parameters for modb are not otherwise specified then modb will draw parameter values from those that would be used by moda if it were declared, whether moda actually is declared or not.
I do have a couple of observations for you to consider, however:
- Your use of the 'require' function suggests that you may not understand its distinction from 'include', as that distinction has no significance whatever in this particular case. 'require' differs only in placing order-of-application constraints, but the params class contains nothing to apply.
- It is unclear why you want to use a data function instead of class parameter defaults in module modb. The result is not, technically, a default value, though it is a reasonable facsimile. Nevertheless, the nature of the relationship between the two modules would be clearer if you used straight-up resource defaults and the standard params class pattern. That that would involve cross-module class inheritance, is moot -- hiding the close inter-module coupling inside a data function is not inherently better than having it obvious in class declarations.
John
Francois Lafont
Jan 6, 2016, 7:39:04 PM1/6/16
to puppet...@googlegroups.com
Hi,
On 04/01/2016 17:01, jcbollinger wrote:
> Your revised idea appears workable.
Ah... cool. ;)
> It establishes class moda::params as a shared data source, along the lines I suggested.
Yes indeed, it's close to what you have proposed.
> It allows module moda to
> be customized, via class moda::params, and if parameters for modb are not
> otherwise specified then modb will draw parameter values from those that
> would be used by moda if it were declared, whether moda actually is
> declared or not.
>
> I do have a couple of observations for you to consider, however:
>
>
> 1. Your use of the 'require' function suggests that you may not
> contains nothing to apply.
Yes, yes, you are absolutely right indeed. "require" is not necessary at all,
a simple "include" is enough and avoid to create useless (and maybe problematic)
"order-of-application" relations. Yes, "include" is enough and perfect. Thanks.
> 2. It is unclear why you want to use a data function instead of class
module modb is to have exactly the same design in all modules. But indeed it's
moot.
Many thanks for your help and your remarks John.
Regard.
François Lafont
On 04/01/2016 17:01, jcbollinger wrote:
> Your revised idea appears workable.
> It establishes class moda::params as a shared data source, along the lines I suggested.
> It allows module moda to
> be customized, via class moda::params, and if parameters for modb are not
> otherwise specified then modb will draw parameter values from those that
> would be used by moda if it were declared, whether moda actually is
> declared or not.
>
> I do have a couple of observations for you to consider, however:
>
>
> understand its distinction from 'include', as that distinction has no
> significance whatever in this particular case. 'require' differs only
> in placing *order-of-application* constraints, but the params class
> significance whatever in this particular case. 'require' differs only
> contains nothing to apply.
Yes, yes, you are absolutely right indeed. "require" is not necessary at all,
a simple "include" is enough and avoid to create useless (and maybe problematic)
"order-of-application" relations. Yes, "include" is enough and perfect. Thanks.
> 2. It is unclear why you want to use a data function instead of class
> parameter defaults in module modb. The result is not, technically, a
> default value, though it is a reasonable facsimile. Nevertheless, the
> nature of the relationship between the two modules would be clearer if you
> used straight-up resource defaults and the standard params class pattern.
> That that would involve cross-module class inheritance, is moot -- hiding
> the close inter-module coupling inside a data function is not inherently
> better than having it obvious in class declarations.
Yes... after thinking, the only reason I see to use the data function in the
> default value, though it is a reasonable facsimile. Nevertheless, the
> nature of the relationship between the two modules would be clearer if you
> used straight-up resource defaults and the standard params class pattern.
> That that would involve cross-module class inheritance, is moot -- hiding
> the close inter-module coupling inside a data function is not inherently
> better than having it obvious in class declarations.
module modb is to have exactly the same design in all modules. But indeed it's
moot.
Many thanks for your help and your remarks John.
Regard.
François Lafont
Reply all
Reply to author
Forward
0 new messages