Re: [Puppet Users] About the params pattern
Hi,
Le 19/09/2014 17:36, jcbollinger a écrit :
The main points I am trying to get across
And I thnink that you have succeeded now. ;)
are these:
1. References to *non-local* variables should always be performed via
qualified names, even when class inheritance makes the variable in
question
accessible also via its unqualified name.
2. All qualified names used should accurately reflect the location of
the referenced entity's declaration (some variables have multiple,
distinct
qualified names).
3. If a class or defined type refers to a variable belonging to a
different class then it should ensure via 'include' / 'require' /
'contain'
or via class inheritance that the variable is initialized first.
It's very clear. Thanks.
I am not saying that references to variables declared *locally* should use
qualified names, but if you want to adopt that practice then it's fine.
With respect to other classes' variables, though, I seem not to be
successfully communicating point (2).
Now I have understood the 3 rules.
I use $::test::xxx in class::internal not $::test::params::xxx
because when xxx is var1 or var2, I want to have the value of
var1 and var2 given as parameters of the test class (I don't want
the default value of var1 and var2).
Yes, that's fine for var1 and var2, but not for foo1 and foo2 which are not
declared by class test. I don't see any particular purpose for foo1 and
foo2 to live in test::params anyway, however, if they are not to be used as
class parameter defaults. You could as easily put them directly in class
test, and then continue to refer to them as you are now doing.
Yes, it's good idea.
Finally, as regards your comments, I think follow this pattern where I follow
your 3 rules, it seems ;):
-
# Example of declaration for the test class.
class { test:
var1 = 'specific_var1',
}
test module with its classes
class test::params {
# API of the module with the default values.
$var1 = 'default_var1'
$var2 = 'default_var2'
}
# The *main* class of the module
class test (
$var1 = $::test::params::var1,
$var2 = $::test::params::var2,
) inherits test::params {
# Shared variables in all classes of the module.
$foo1 = 'value_foo1'
$foo2 = 'value_foo2'
include ::test::internal
# Here, I could use $var1, $var2, $foo1, $foo2
# (only in the main class of the module).
notify { 'v1': message = var1 = $::test::var1, }
notify { 'v2': message = var2 = $::test::var2, }
notify { 'f1': message = foo1 = $::test::foo1, }
notify { 'f2': message = foo2 = $::test::foo2, }
# etc.
}
class test::internal {
# It's an internal class of the module test which will be
# never called by the user. So, the line below is useless.
# It's just for self-documenting.
# Maybe I could remove this line, I don't know...
require ::test
notify { 'iv1': message = Internal var1 = $::test::var1, }
notify { 'iv2': message = Internal var2 = $::test::var2, }
notify { 'if1': message = Internal foo1 = $::test::foo1, }
notify { 'if2': message = Internal foo2 = $::test::foo2, }
# So, in templates, I use the syntax scope['::test::var']
file { '/tmp/internal.txt':
content = inline_template(var1=%= scope['::test::var1'] %\nfoo2=%=
scope['::test::foo2'] %\n),
}
}
-
By the way, don't be confused about the meaning of the 'include' statement,
or its siblings 'require' and 'contain'. 'Include' says that the named
class must be included *in the catalog*; it does NOT interpolate the named
class's body in place of the include statement (i.e. it is not analogous to
a C preprocessor #include directive). A given class can be the subject of
any number of 'include', 'require', and 'contain' statements; no class will
appear in the catalog more than once.
Yes, it's clear and even clearer with your link below.
In part, it looks like you are running into bug 1220
https://tickets.puppetlabs.com/browse/PUP-1220.
Yes, this is exactly my problem!
That was reported fixed
in Puppet 3.5.0, but if I understand correctly, you need to enable the
future parser to actually activate the bug fix (which would make the
variable reference in your template fail to resolve in both cases).
I confirm. If I put:
parser = future
in the puppet.conf (in [main] section), I have the expected behaviour.
To my mind, the execpted behaviour (explained in the puppet documentation)
occurs with parser = future which is *not* enabled by default.
It's curious, but not a problem for me. I guess it's a backward
compatibility problem...
And in this case, I don't understand. I thought that :
$var1 = value_var1 # LINE A
include ::test::internal # LINE B
and
include ::test::internal # LINE B
$var1 = value_var1 # LINE A
was completely equivalent. Am I wrong?
Re: [Puppet Users] About the params pattern
What you've stumbled on is the concept of public and private classes.
Public and private
classes are implemented very differently. A public class is your module's
entry point,
this is how people interact with your module. A public class is where you
define your
module's API. Private classes, on the other hand, are not meant to be
called outside your
module. Private classes are the meat of your module. This is where you will
actually
implement your module's functionality. A public class should be the only
way a user can
interact with your private classes. Public classes should generally do very
little. I
typically limit my public classes to validating the inputs received by my
parameters and
calling my private classes. Since examples speak louder than words, here's
an example:
# my_module/manifests/init.pp
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# Validate my parameters
validate_string($var1)
validate_array($var2)
validate_bool($var3)
# Call my 'private' classes
class { 'my_module::install': } -
class {'my_module::config': } ~
class {'my_module::service'} -
Class['my_module']
}
The 'my_module' class is my public class. It has three parameters. All this
class does is
validate my three parameters and call my private classes. Let's take a look
at those
private classes:
# my_module/manifests/install.pp
class my_module::install (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
) {
private()
# Body of the class
...
}
# my_module/manifests/config.pp
class my_module::config (
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
# my_module/manifests/service.pp
class my_module::service (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
As you can see, I've marked my private classes with the private function.
This function
has not yet been released in stdlib, but is available in trunk
(https://github.com/puppetlabs/puppetlabs-stdlib#private). Google can show
you how
to implement this functionality in the DSL, if you prefer. The private
classes concept
allows us to make some assumptions that affect the design of this module,
specifically,
calling the variables in my_module without inheriting it first. We're
assuming that, since
this is a private class, it will not be called independently of my_module,
and those
variables will always be accessible.
This pattern can be found in a number of modules on the forge. Note, that
these modules
don't use the private function since it hasn't been released yet. They
assume that the
private classes are only being called inside their module. Here are some
examples:
https://github.com/garethr/garethr-docker
https://github.com/puppetlabs/puppetlabs-mysql
https://github.com/puppetlabs/puppetlabs-ntp
This is emerging very quickly as a good design pattern that fosters
modularity,
simplicity, good separation of concerns, and clear data flow.
On Monday, September 22, 2014 4:01:19 AM UTC-7, François Lafont wrote:
Hi,
Le 19/09/2014 17:36, jcbollinger a écrit :
The main points I am trying to get across
And I thnink that you have succeeded now. ;)
are these:
1. References to *non-local* variables should always be performed via
qualified names, even when class inheritance makes the variable in
question
accessible also via its unqualified name.
2. All qualified names used should accurately reflect the location of
the referenced entity's declaration (some variables have multiple,
distinct
qualified names).
3. If a class or defined type refers to a variable belonging to a
different class then it should ensure via 'include' / 'require' /
'contain'
or via class inheritance that the variable is initialized first.
It's very clear. Thanks.
I am not saying that references to variables declared *locally* should
use
qualified names, but if you want to adopt that practice then it's fine.
With respect to other classes' variables, though, I seem not to be
successfully communicating point (2).
Now I have understood the 3 rules.
I use $::test::xxx in class::internal not $::test::params::xxx
because when xxx is var1 or var2, I want to have the value of
var1 and var2 given as parameters of the test class (I don't want
the default value of var1 and var2).
Yes, that's fine for var1 and var2, but not for foo1 and foo2 which are
not
declared by class test. I don't see any particular purpose for foo1 and
foo2 to live in test::params anyway, however, if they are not to be used
as
class parameter defaults. You could as easily put them directly in
class
test, and then continue to refer to them as you are now doing.
Yes, it's good idea.
Re: [Puppet Users] About the params pattern
What you've stumbled on is the concept of public and private classes.
Public and private
classes are implemented very differently. A public class is your module's
entry point,
this is how people interact with your module. A public class is where you
define your
module's API. Private classes, on the other hand, are not meant to be
called outside your
module. Private classes are the meat of your module. This is where you will
actually
implement your module's functionality. A public class should be the only
way a user can
interact with your private classes. Public classes should generally do very
little. I
typically limit my public classes to validating the inputs received by my
parameters and
calling my private classes. Since examples speak louder than words, here's
an example:
# my_module/manifests/init.pp
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# Validate my parameters
validate_string($var1)
validate_array($var2)
validate_bool($var3)
# Call my 'private' classes
class { 'my_module::install': } -
class {'my_module::config': } ~
class {'my_module::service'} -
Class['my_module']
}
The 'my_module' class is my public class. It has three parameters. All this
class does is
validate my three parameters and call my private classes. Let's take a look
at those
private classes:
# my_module/manifests/install.pp
class my_module::install (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
) {
private()
# Body of the class
...
}
# my_module/manifests/config.pp
class my_module::config (
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
# my_module/manifests/service.pp
class my_module::service (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
As you can see, I've marked my private classes with the private function.
This function
has not yet been released in stdlib, but is available in trunk
(https://github.com/puppetlabs/puppetlabs-stdlib#private). Google can show
you how
to implement this functionality in the DSL, if you prefer. The private
classes concept
allows us to make some assumptions that affect the design of this module,
specifically,
calling the variables in my_module without inheriting it first. We're
assuming that, since
this is a private class, it will not be called independently of my_module,
and those
variables will always be accessible.
This pattern can be found in a number of modules on the forge. Note, that
these modules
don't use the private function since it hasn't been released yet. They
assume that the
private classes are only being called inside their module. Here are some
examples:
https://github.com/garethr/garethr-docker
https://github.com/puppetlabs/puppetlabs-mysql
https://github.com/puppetlabs/puppetlabs-ntp
This is emerging very quickly as a good design pattern that fosters
modularity,
simplicity, good separation of concerns, and clear data flow.
--
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/95a01d6a-f6b0-48bd-b47b-bf9ab99773e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
Hi,
Le 22/09/2014 15:16, David Danzilio a écrit :
What you've stumbled on is the concept of public and private classes.
Not exactly I think. The concept of public and private classes
was clear for me. It was the *implementation* of the params
pattern which was not clear for me, especially for private
classes. I think it's ok now. ;)
Public and private classes are implemented very differently.
A public class is your module's entry point, this is how
people interact with your module. A public class is where you
define your module's API. Private classes, on the other hand,
are not meant to be called outside your module. Private classes
are the meat of your module. This is where you will actually
implement your module's functionality. A public class should
be the only way a user can interact with your private classes.
Public classes should generally do very little. I typically
limit my public classes to validating the inputs received by
my parameters and calling my private classes.
Totally agree with that. No problem.
Since examples speak louder than words, here's an example:
# my_module/manifests/init.pp
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# Validate my parameters
validate_string($var1)
validate_array($var2)
validate_bool($var3)
# Call my 'private' classes
class { 'my_module::install': } -
class {'my_module::config': } ~
class {'my_module::service'} -
Class['my_module']
}
The 'my_module' class is my public class. It has three parameters. All this
class does is validate my three parameters and call my private classes.
Let's take a look at those private classes:
# my_module/manifests/install.pp
class my_module::install (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
) {
private()
# Body of the class
...
}
# my_module/manifests/config.pp
class my_module::config (
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
# my_module/manifests/service.pp
class my_module::service (
$var1 = $my_module::var1,
$var2 = $my_module::var2,
$var3 = $my_module::var3,
) {
private()
# Body of the class
...
}
Ok, it looks like what I gave in my previous message except:
1. the private() function. I didn't know it.
2. In my case, in a private class, I don't use parameters
and I use the variables of the public class directly with
the fully qualified name :
class my_module::service {
notify { var1 = $::my_module::var1: }
# etc.
}
Thus, I don't have to write the parameters of the public class for *each*
private class. But, in return, I have to use the fully the qualified names
of these variables. ;)
As you can see, I've marked my private classes with the private function.
This function has not yet been released in stdlib, but is available in trunk
(https://github.com/puppetlabs/puppetlabs-stdlib#private).
Thank you. Very interesting.
Google can show you how to implement this functionality in the DSL,
if you prefer. The private classes concept allows us to make some assumptions
that affect the design of this module, specifically, calling the variables
in my_module without inheriting it first. We're assuming that, since this is
a private class, it will not be called independently of my_module, and those
variables will always be accessible.
This pattern can be found in a number of modules on the forge. Note, that
these modules don't use the private function since it hasn't been released
yet. They assume that the private classes are only being called inside their
module. Here are some examples:
https://github.com/garethr/garethr-docker
https://github.com/puppetlabs/puppetlabs-mysql
https://github.com/puppetlabs/puppetlabs-ntp
This is emerging very quickly as a good design pattern that fosters
modularity, simplicity, good separation of concerns, and clear data flow.
Ok, thanks for your remarks.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/54204073.9060906%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
On 09/18/2014 04:40 PM, jcbollinger wrote: I'm not prepared to set up and run this test, but if it genuinely produces the results you describe then that demonstrates a bug. Here are the docs on Puppet scope: https://docs.puppetlabs.com/puppet/3/reference/lang_scope.html. Here are the docs on referencing variables from templates: https://docs.puppetlabs.com/guides/templating.html#referencing-variables. Inasmuch as this is one of the more heavily used areas of Puppet, I suspect that something else is going on in your environment, but if such a bug has indeed cropped up then I'm sure PuppetLabs would appreciate a bug report. Aw man, that thread is way too voluminous for me to read in a spare minute. But since you bring up templates - there was that bug, yes. https://tickets.puppetlabs.com/browse/PUP-1220 It led to dynamic scoping rearing its ugly head again, when variables were used in templates. Not sure if this is the issue here, but it might. The OP can verify this by setting parser=future. Cheers, Felix -- 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/54204A86.3030707%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
Le 22/09/2014 18:12, Felix Frank a écrit : Aw man, that thread is way too voluminous for me to read in a spare minute. Yes, sorry. It's a long thread but it's a finished thread I think. ;) But since you bring up templates - there was that bug, yes. https://tickets.puppetlabs.com/browse/PUP-1220 It led to dynamic scoping rearing its ugly head again, when variables were used in templates. Not sure if this is the issue here, but it might. The OP can verify this by setting parser=future. Yes, I have confirmed here: ;) On Monday, September 22, 2014 4:01:19 AM UTC-7, François Lafont wrote: I confirm. If I put: parser = future in the puppet.conf (in [main] section), I have the expected behaviour. To my mind, the execpted behaviour (explained in the puppet documentation) occurs with parser = future which is *not* enabled by default. It's curious, but not a problem for me. I guess it's a backward compatibility problem... 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/54204C36.2060608%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
On 09/22/2014 06:20 PM, Francois Lafont wrote: But since you bring up templates - there was that bug, yes. https://tickets.puppetlabs.com/browse/PUP-1220 It led to dynamic scoping rearing its ugly head again, when variables were used in templates. Not sure if this is the issue here, but it might. The OP can verify this by setting parser=future. Yes, I have confirmed here: ;) \o/ Thanks -- 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/54204DD0.1080004%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
On Thursday, September 18, 2014 5:59:56 PM UTC-5, François Lafont wrote:
Hi,
Le 18/09/2014 16:40, jcbollinger a écrit :
So, finally, is this way below a correct and good way to use the params
pattern?
-
# Example of declaration for the test class.
class { test:
var1 = 'specific_var1',
}
test module with its classes
class test::params {
# API
$var1 = 'default_var1'
$var2 = 'default_var2'
# Shared variables
$foo1 = 'value_foo1'
$foo2 = 'value_foo2'
}
# The main class of the module
# I use fully qualified variable names exclusively!
class test (
$var1 = $::test::params::var1,
$var2 = $::test::params::var2,
) inherits test::params {
include ::test::internal
notify { 'v1': message = var1 = $::test::var1, }
notify { 'v2': message = var2 = $::test::var2, }
notify { 'f1': message = foo1 = $::test::foo1, }
notify { 'f2': message = foo2 = $::test::foo2, }
}
The main points I am trying to get across are these:
1. References to *non-local* variables should always be performed via
qualified names, even when class inheritance makes the variable in question
accessible also via its unqualified name.
2. All qualified names used should accurately reflect the location of
the referenced entity's declaration (some variables have multiple, distinct
qualified names).
3. If a class or defined type refers to a variable belonging to a
different class then it should ensure via 'include' / 'require' / 'contain'
or via class inheritance that the variable is initialized first.
I am not saying that references to variables declared *locally* should use
qualified names, but if you want to adopt that practice then it's fine.
With respect to other classes' variables, though, I seem not to be
successfully communicating point (2). There are two formulations for your
class test that I would consider good form, neither one exactly what you
presented above.
*Alternative 1:*
class test (
$var1 = $::test::params::var1,
$var2 = $::test::params::var2,
) inherits test::params {
include ::test::internal
notify { 'v1': message = var1 = *$var1*, }
notify { 'v2': message = var2 = *$var2*, }
notify { 'f1': message = foo1 = *$::test::params::foo1*, }
notify { 'f2': message = foo2 = *$::test::params::foo2*, }
}
*Alternative 2:*
class test (
$var1 = $::test::params::var1,
$var2 = $::test::params::var2,
) inherits test::params {
include ::test::internal
notify { 'v1': message = var1 = $::test::var1, }
notify { 'v2': message = var2 = $::test::var2, }
notify { 'f1': message = foo1 = *$::test::params::foo1*, }
notify { 'f2': message = foo2 = *$::test::params::foo2*, }
}
I would also be ok with using qualified but not absolute variable
references of the form $test::params::foo1, but the absolute versions you
presented are slightly safer.
Either way, the only variables foo1 and foo2 in the module belong to
class test::params. All references to them should be relative to their
declaring class (test::params), notwithstanding the fact that because of
class inheritance, Puppet should still find them if you instead qualify
them with namespace test::.
class test::internal {
notify { 'iv1': message = Internal var1 = $::test::var1, }
notify { 'iv2': message = Internal var2 = $::test::var2, }
notify { 'if1': message = Internal foo1 = $::test::foo1, }
notify { 'if2': message = Internal foo2 = $::test::foo2, }
As above, references to variables foo1 and foo2 should be qualifed by
namespace 'test::params', not namespace 'test'.
Furthermore, this class definition above does not ensure that variables
$::test::var1, $::test::var2, $::test::params::foo1, and
$::test::params::foo2 have been initialized. If it is in fact declared
only by class test then that will work out, because class test provides
those assurances. Generally speaking, it would be better form for class
test::inner to take that into its own hands, as doing so would make the
class both more flexible and more self-documenting. In this particular
case, however, that would involve class test::inner 'include'ing class
test, and that's not sensible when class test is also including
test::inner.
So, that's mostly OK, with the caveats that references to foo1 and foo2
should be differently qualified, and that class test::inner is encumbered
with usage restrictions.
# So, in templates, I use the syntax scope['::test::var']
# (I'm using Puppet 3.7.1 so - scope[...])
file { '/temp/internal.txt':
content = inline_template(var1=%= scope['::test::var1']
%\nfoo2=%= scope['::test::foo2'] %\n),
}
Again, qualify references to foo2 more appropriately:
file { '/temp/internal.txt':
content = inline_template(var1=%= scope['::test::var1'] %\nfoo2=%=
Re: [Puppet Users] About the params pattern
On Wednesday, September 17, 2014 10:55:12 PM UTC-5, François Lafont wrote:
Thank you for your answer.
Le 17/09/2014 17:12, jcbollinger a écrit :
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
) inherits my_module::params {
include my_module
There's no point to including class my_module inside its own definition.
Did you mean to include my_module::internal?
Yes exactly. Sorry for the mistake.
class my_module::internal {
file { '/tmp/test_internal.txt':
content = template('test/test_internal.txt.erb'),
}
notify { 'm1': message = var1 = ${my_module::var1}, }
notify { 'm2': message = var2 = ${my_module::var2}, }
notify { 'm3': message = foo1 = ${my_module::foo1}, }
notify { 'm4': message = foo2 = ${my_module::foo2}, }
}
It's curious because I use no inheritance in my_module::internal,
no require etc. and despite that I can access to the variables of
my_module. Is it normal?
It is very poor form to access $my_module::params::foo1 and
$my_module::params::foo2 via inheriting class my_module (i.e. as
${my_module::foo1}, etc.).
But the my_module::internal inherits no class, so doesn't inherit
my_module class? I don't see where is the inheritance in the code
above.
Sorry, I worded that very poorly.
Class my_module inherits my_module::params. Absent my_module declaring its
own local variables $foo1 and $foo2, the inheritance results in variables
$::my_module::params::foo1 and $::my_module::params::foo2 being accessible
unqualified in class my_module's namespace. Because those variables are
accessible unqualified in class my_module, they are also accessible
elsewhere qualified by namespace my_module (i.e. $::my_module::foo1) --
*that* little bit of evil should not be used. Instead, always qualify
variable references with the namespace in which the variable is actually
declared (my_module::params in this case).
Or, if I understand well, when I have:
class my_module {
include my_module::internal
}
I can say: my_module::internal inherits my_module. Is that correct?
No, not at all. My apologies for the confusion.
With that out of the way, it is better to say
that the result you observe is among the valid possibilities than to say
it
is normal.
All class variables have global visibility regardless of inheritance or
declaration (e.g. via include / require).
Do you mean that with:
class my_module {
include my_module::internal
}
In the body of my_module::internal class I can access to the variables
defined in my_module class? With a unqualified name?
No, not in the slightest. I mean that if class my_module::params has a
local variable with unqualified name foo1, then that variable can be
referenced from any class in any module as $my_module::params::foo1,
regardless of any inheritance or include / require / contain statements
anywhere. Under some inheritance-related circumstances it can also be
referenced in certain places via its unqualified name, but as a matter of
form, it should be accessed only via its qualified name anywhere outside
class my_module::params.
The main role of inheritance and the only role of include / require /
contain with respect to class variables is as I described before:
The main purpose of all that *as
it pertains to variables* is to ensure that Puppet evaluates classes
during
catalog compilation in an order that assigns values to those variables
before those values are used. It also serves a documentary purpose,
showing clearly that one class has a dependency on another.
One thing very curious too: in the my_module::internal class
I can access to $var1 with this syntax :
${my_module::var1}
No, you can't. There is no $var1 in class my_module::internal, so you
are
not accessing such a variable. You are instead accessing
$my_module::params::var1 via an alias (that alias resulting from class
my_module inheriting my_module::params). Don't use that alias, even in
class my_module.
Ok.
No, not ok, my apologies. There is after all a $my_module:var1 -- it is a
class parameter. I overlooked that this is a different case from the
$my_module::foo1 case discussed above. So, it's right and fine to refer to
$my_module::var1 if that's what you actually mean.
and $var1 is empty. Ok, I think I understand that. But in my
template test_internal.txt.erb I can use directly:
blabla %= @var1 % blabla
without the fully qualified name. Here, I don't understand.
I don't believe you.
I can give you a precise and quick (if you have already a Debian Wheezy)
process to reproduct this. I take a Debian Wheezy, updated and cleaned
(it's a simple VM in Virtualbox). And here is the process:
I'm not prepared to set up and
Re: [Puppet Users] About the params pattern
Hi,
Le 18/09/2014 16:40, jcbollinger a écrit :
Sorry, I worded that very poorly.
Really no problem. ;)
Class my_module inherits my_module::params. Absent my_module declaring its
own local variables $foo1 and $foo2, the inheritance results in variables
$::my_module::params::foo1 and $::my_module::params::foo2 being accessible
unqualified in class my_module's namespace. Because those variables are
accessible unqualified in class my_module, they are also accessible
elsewhere qualified by namespace my_module (i.e. $::my_module::foo1) --
*that* little bit of evil should not be used. Instead, always qualify
variable references with the namespace in which the variable is actually
declared (my_module::params in this case).
Ok. Indeed I have read in Puppet documentation that it's better to avoid
unqualified variable (I have seen it's a wolf trap) and it's better to
use fully qualified variable.
So, finally, is this way below a correct and good way to use the params
pattern?
-
# Example of declaration for the test class.
class { test:
var1 = 'specific_var1',
}
test module with its classes
class test::params {
# API
$var1 = 'default_var1'
$var2 = 'default_var2'
# Shared variables
$foo1 = 'value_foo1'
$foo2 = 'value_foo2'
}
# The main class of the module
# I use fully qualified variable names exclusively!
class test (
$var1 = $::test::params::var1,
$var2 = $::test::params::var2,
) inherits test::params {
include ::test::internal
notify { 'v1': message = var1 = $::test::var1, }
notify { 'v2': message = var2 = $::test::var2, }
notify { 'f1': message = foo1 = $::test::foo1, }
notify { 'f2': message = foo2 = $::test::foo2, }
}
class test::internal {
notify { 'iv1': message = Internal var1 = $::test::var1, }
notify { 'iv2': message = Internal var2 = $::test::var2, }
notify { 'if1': message = Internal foo1 = $::test::foo1, }
notify { 'if2': message = Internal foo2 = $::test::foo2, }
# So, in templates, I use the syntax scope['::test::var']
# (I'm using Puppet 3.7.1 so - scope[...])
file { '/temp/internal.txt':
content = inline_template(var1=%= scope['::test::var1'] %\nfoo2=%=
scope['::test::foo2'] %\n),
}
}
-
I use $::test::xxx in class::internal not $::test::params::xxx
because when xxx is var1 or var2, I want to have the value of
var1 and var2 given as parameters of the test class (I don't want
the default value of var1 and var2).
Like this, it all seems to you correct?
No, not in the slightest. I mean that if class my_module::params has a
local variable with unqualified name foo1, then that variable can be
referenced from any class in any module as $my_module::params::foo1,
regardless of any inheritance or include / require / contain statements
anywhere.
Hum... there is exception, isn't? For instance, it depends of the
order of the class in the catalog, I'm wrong?
For instance, with this manifest:
-
include ::test1
include ::test2
class test1 {
$var1 = var1
notify { 'm1': message = var2 = $::test2::var2, }
}
class test2 {
$var2 = var2
notify { 'm2': message = var1 = $::test1::var1, }
}
-
I have this result:
~$ puppet apply manifest.pp
Warning: Scope(Class[Test1]): Could not look up qualified variable
'::test2::var2'; class ::test2 has not been evaluated
Notice: Compiled catalog for wheezy-clean.chezmoi.priv in environment
production in 0.02 seconds
Notice: var1 = var1
Notice: /Stage[main]/Test2/Notify[m2]/message: defined 'message' as 'var1 =
var1'
Notice: var2 =
Notice: /Stage[main]/Test1/Notify[m1]/message: defined 'message' as 'var2 = '
Notice: Finished catalog run in 0.41 seconds
I can give you a precise and quick (if you have already a Debian Wheezy)
process to reproduct this. I take a Debian Wheezy, updated and cleaned
(it's a simple VM in Virtualbox). And here is the process:
I'm not prepared to set up and run this test,
Ok. Let me show you an even faster test than the previous test (no installation
of puppetmaster just the puppet agent) :
root@wheezy-clean:~# lsb_release -sc
wheezy
root@wheezy-clean:~# wget
https://apt.puppetlabs.com/puppetlabs-release-$(lsb_release -sc).deb
root@wheezy-clean:~# dpkg -i puppetlabs-release-$(lsb_release -sc).deb
root@wheezy-clean:~# apt-get update
root@wheezy-clean:~# apt-get install puppet
root@wheezy-clean:~# puppet -V
3.7.1
# Just comment the templatedir line in puppet.conf (which is deprecated)
root@wheezy-clean:~# sed -i -r 's/^(templatedir.*)$/#\1/g'
/etc/puppet/puppet.conf
# Create a simple manifest.
root@wheezy-clean:~# vim manifest.pp
Here is my (very) simple manifest:
--
include ::test
class test {
$var1 = value_var1 # LINE A
include ::test::internal # LINE B
}
class
Re: [Puppet Users] About the params pattern
Le 17/09/2014 04:26, Sebastian Otaegui a écrit :
As far as I know inner classes are an anti pattern(for the lack of a
better term)
Each class should live in its own file.
More than one class per file is discouraged
I agree. It's better to define inner classes in separate files
(my_module::internal1 in my_module/internal1.pp, my_module::internal2
in my_module/internal2.pp etc).
But this is not really my question. My question is: which pattern should
I use:
a) to define inner classes (indeed in a specific file)
b) and to call inner classes in the my_module class (which is the
top level class called by the user of my_module)
knowing that a inner class needs to use variables defined in
my_module::params, but among these variables, maybe severals
variables are parameters of the my_module class with a different
value of the default value proposed in my_module::params.
For instance with:
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# The body of the class
}
and:
class my_module::params {
## API of the module ##
$var1 = default_value1
$var2 = default_value2
$var3 = default_value3
## shared variables between the classes of my_module
## but they are not part of the API module
$foo1 = default_value_foo1
$foo2 = default_value_foo2
$foo3 = default_value_foo3
...
}
Imagine I want to define an inner class internal which
needs to use $var2, $var3, $foo1 and $foo2. Which pattern
should I use to define my internal class.
This one?
class my_module::internal (
$var2,
$var3,
) inherits my_module::params {
notify { value of foo1 - $foo1: }
notify { value of foo2 - $foo2: }
}
This one?
class my_module::internal (
$var2,
$var3,
) {
require my_module::params
notify { value of foo1 - $my_module:params::foo1: }
notify { value of foo2 - $my_module:params::foo2: }
}
Or maybe another one...?
In the article that I pointed out in my first message, the
parttern to use to define the top level class is clearly
explained. This is:
class my_module (
# API of my_module
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# The body of the class
}
But the article doesn't explain the pattern to use to define
an inner class (which needs to use variables defined in
my_module::params too and needs to use some variables in
the parameters of my_module class).
I hope I'm clear in my question.
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/541942FD.2020005%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
Le 17/09/2014 10:14, Francois Lafont a écrit :
For instance with:
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# The body of the class
}
and:
class my_module::params {
## API of the module ##
$var1 = default_value1
$var2 = default_value2
$var3 = default_value3
## shared variables between the classes of my_module
## but they are not part of the API module
$foo1 = default_value_foo1
$foo2 = default_value_foo2
$foo3 = default_value_foo3
...
}
Imagine I want to define an inner class internal which
needs to use $var2, $var3, $foo1 and $foo2. Which pattern
should I use to define my internal class.
This one?
class my_module::internal (
$var2,
$var3,
) inherits my_module::params {
notify { value of foo1 - $foo1: }
notify { value of foo2 - $foo2: }
}
This one?
class my_module::internal (
$var2,
$var3,
) {
require my_module::params
notify { value of foo1 - $my_module:params::foo1: }
notify { value of foo2 - $my_module:params::foo2: }
}
Or maybe another one...?
In fact, It's curious. I have made some tests with puppet 3.7.0
on Debian Wheezy and I can simply do this:
class my_module::params {
## API of the module ##
$var1 = default_value1
$var2 = default_value2
## shared variables between the classes of my_module
## but they are not part of the API module
$foo1 = default_value_foo1
$foo2 = default_value_foo2
...
}
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
) inherits my_module::params {
include my_module
}
class my_module::internal {
file { '/tmp/test_internal.txt':
content = template('test/test_internal.txt.erb'),
}
notify { 'm1': message = var1 = ${my_module::var1}, }
notify { 'm2': message = var2 = ${my_module::var2}, }
notify { 'm3': message = foo1 = ${my_module::foo1}, }
notify { 'm4': message = foo2 = ${my_module::foo2}, }
}
It's curious because I use no inheritance in my_module::internal,
no require etc. and despite that I can access to the variables of
my_module. Is it normal?
One thing very curious too: in the my_module::internal class
I can access to $var1 with this syntax :
${my_module::var1}
and $var1 is empty. Ok, I think I understand that. But in my
template test_internal.txt.erb I can use directly:
blabla %= @var1 % blabla
without the fully qualified name. Here, I don't understand.
Anyway, although I do not understand well the scope mechanism
etc. I feel that I can just use this design for inner classes :
class my_module::internal {
# No inheritance, no require of my_module::params etc.
# It's unnecessary.
# In the class, I must use the fully qualified name
# to access to a variable of my_module inherited by
# my_module::params (and sometimes overwritten).
# For instance:
notify { 'm1': message = var1 = ${my_module::var1}, }
# But in templates, I can directy use @var1.
}
Am I wrong?
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/54196F0D.4080909%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
On Wednesday, September 17, 2014 3:15:44 AM UTC-5, François Lafont wrote:
Le 17/09/2014 04:26, Sebastian Otaegui a écrit :
As far as I know inner classes are an anti pattern(for the lack of a
better term)
Nested classes are poor form, but multiple classes in the same module are
fine.
Each class should live in its own file.
More than one class per file is discouraged
More specifically, nesting classes or defined types inside other classes is
widely considered poor form these days, and it *will* cause you grief
unless you know exactly what you're doing or you get very, very lucky.
Putting multiple un-nested classes or definitions in the same file (or
otherwise arranging classes and definitions differently than the autoloader
is prepared to handle) is even worse form, and even if you know what you're
doing you probably cannot make that work smoothly without resorting to
near-deprecated 'import'.
I agree. It's better to define inner classes in separate files
I prefer the terminology module classes, as distinguished from the
module main class or main module class. The term inner class carries
too much baggage, and anyway, sometimes module classes are not intended to
be private to the module.
(my_module::internal1 in my_module/internal1.pp, my_module::internal2
in my_module/internal2.pp etc).
But this is not really my question. My question is: which pattern should
I use:
a) to define inner classes (indeed in a specific file)
b) and to call inner classes in the my_module class (which is the
top level class called by the user of my_module)
knowing that a inner class needs to use variables defined in
my_module::params, but among these variables, maybe severals
variables are parameters of the my_module class with a different
value of the default value proposed in my_module::params.
Do not get hung up on class inheritance, and especially do not confuse the
usage of the terms class and inheritance in Puppet context with the
usage of the same terms in OOP context. Puppet classes are not classes in
the OO sense, and Puppet class inheritance has significant dissimilarities
from typical OO class inheritance.
Moreover, with respect to your actual question, it is important to
understand the purpose of class inheritance as it applies to the params
class pattern: its *only* purpose in that context is to ensure that the
::params class is evaluated (and thus its variables assigned their values)
before the parameter list of the inheriting class is evaluated. That makes
it safe for variables of the ::params class to be used as class parameter
defaults in the inheriting class. Note, too, that that effect is merely a
side effect of class inheritance, not its true purpose.
If a given module class uses variables of the module's ::params class, but
none of them as (its own) parameter defaults, then it can 'include
my_module::params' in its body instead of inheriting from the params
class. If a module class does use ::params class variables as default
values for its own parameters, however, then it should inherit from the
params class both for documentary and for self-containment purposes.
For instance with:
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# The body of the class
}
and:
class my_module::params {
## API of the module ##
$var1 = default_value1
$var2 = default_value2
$var3 = default_value3
## shared variables between the classes of my_module
## but they are not part of the API module
$foo1 = default_value_foo1
$foo2 = default_value_foo2
$foo3 = default_value_foo3
...
}
Imagine I want to define an inner class internal which
needs to use $var2, $var3, $foo1 and $foo2. Which pattern
should I use to define my internal class.
This one?
class my_module::internal (
$var2,
$var3,
) inherits my_module::params {
notify { value of foo1 - $foo1: }
notify { value of foo2 - $foo2: }
}
No, if only because you are using the variables $my_module::params::foo1
and $my_module::params::foo2 without qualifying their names. It works, but
it is poor form. In this particular case it is also confusing, because
class parameters $my_module::internal::var2 and $my_module::internal::var3
have the same unqualified names as variables of class my_module::params,
but they are completely separate variables.
This one?
class my_module::internal (
$var2,
$var3,
) {
require my_module::params
notify { value of foo1 - $my_module:params::foo1: }
notify { value of foo2 - $my_module:params::foo2: }
}
It would be better to use 'include' than 'require' in this case, and you
mis-typed a couple of your namespace separators, but basically that's fine.
Or maybe another one...?
Re: [Puppet Users] About the params pattern
This is what I do. This way the sub-classes automatically get variables
defaults from the parent-class and when using the module you should only
have to call the parent class; as long as you have defined all your
parameters that are used by any sub-model in the parent class.
class module (
$var0 = $::module::params::var0,
$var1 = $::module::params::var1,
) inherits ::module::params {
include module::file
include module::package
}
class module::file (
$var0 = $::module::var0
) { }
class module::package (
$var1 = $::module::var1
) { }
On Wed, Sep 17, 2014 at 7:49 AM, jcbollinger john.bollin...@stjude.org
wrote:
On Wednesday, September 17, 2014 3:15:44 AM UTC-5, François Lafont wrote:
Le 17/09/2014 04:26, Sebastian Otaegui a écrit :
As far as I know inner classes are an anti pattern(for the lack of a
better term)
Nested classes are poor form, but multiple classes in the same module are
fine.
Each class should live in its own file.
More than one class per file is discouraged
More specifically, nesting classes or defined types inside other classes
is widely considered poor form these days, and it *will* cause you grief
unless you know exactly what you're doing or you get very, very lucky.
Putting multiple un-nested classes or definitions in the same file (or
otherwise arranging classes and definitions differently than the autoloader
is prepared to handle) is even worse form, and even if you know what you're
doing you probably cannot make that work smoothly without resorting to
near-deprecated 'import'.
I agree. It's better to define inner classes in separate files
I prefer the terminology module classes, as distinguished from the
module main class or main module class. The term inner class carries
too much baggage, and anyway, sometimes module classes are not intended to
be private to the module.
(my_module::internal1 in my_module/internal1.pp, my_module::internal2
in my_module/internal2.pp etc).
But this is not really my question. My question is: which pattern should
I use:
a) to define inner classes (indeed in a specific file)
b) and to call inner classes in the my_module class (which is the
top level class called by the user of my_module)
knowing that a inner class needs to use variables defined in
my_module::params, but among these variables, maybe severals
variables are parameters of the my_module class with a different
value of the default value proposed in my_module::params.
Do not get hung up on class inheritance, and especially do not confuse the
usage of the terms class and inheritance in Puppet context with the
usage of the same terms in OOP context. Puppet classes are not classes in
the OO sense, and Puppet class inheritance has significant dissimilarities
from typical OO class inheritance.
Moreover, with respect to your actual question, it is important to
understand the purpose of class inheritance as it applies to the params
class pattern: its *only* purpose in that context is to ensure that the
::params class is evaluated (and thus its variables assigned their values)
before the parameter list of the inheriting class is evaluated. That makes
it safe for variables of the ::params class to be used as class parameter
defaults in the inheriting class. Note, too, that that effect is merely a
side effect of class inheritance, not its true purpose.
If a given module class uses variables of the module's ::params class, but
none of them as (its own) parameter defaults, then it can 'include
my_module::params' in its body instead of inheriting from the params
class. If a module class does use ::params class variables as default
values for its own parameters, however, then it should inherit from the
params class both for documentary and for self-containment purposes.
For instance with:
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
) inherits my_module::params {
# The body of the class
}
and:
class my_module::params {
## API of the module ##
$var1 = default_value1
$var2 = default_value2
$var3 = default_value3
## shared variables between the classes of my_module
## but they are not part of the API module
$foo1 = default_value_foo1
$foo2 = default_value_foo2
$foo3 = default_value_foo3
...
}
Imagine I want to define an inner class internal which
needs to use $var2, $var3, $foo1 and $foo2. Which pattern
should I use to define my internal class.
This one?
class my_module::internal (
$var2,
$var3,
) inherits my_module::params {
notify { value of foo1 - $foo1: }
notify { value of foo2 - $foo2: }
}
No, if only because you are using the variables $my_module::params::foo1
and $my_module::params::foo2 without qualifying their names. It works, but
it is poor form. In this particular case it is also confusing, because
class parameters
Re: [Puppet Users] About the params pattern
On Wednesday, September 17, 2014 6:22:52 AM UTC-5, François Lafont wrote:
In fact, It's curious. I have made some tests with puppet 3.7.0
on Debian Wheezy and I can simply do this:
class my_module::params {
## API of the module ##
$var1 = default_value1
$var2 = default_value2
## shared variables between the classes of my_module
## but they are not part of the API module
$foo1 = default_value_foo1
$foo2 = default_value_foo2
...
}
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
) inherits my_module::params {
include my_module
There's no point to including class my_module inside its own definition.
Did you mean to include my_module::internal?
}
class my_module::internal {
file { '/tmp/test_internal.txt':
content = template('test/test_internal.txt.erb'),
}
notify { 'm1': message = var1 = ${my_module::var1}, }
notify { 'm2': message = var2 = ${my_module::var2}, }
notify { 'm3': message = foo1 = ${my_module::foo1}, }
notify { 'm4': message = foo2 = ${my_module::foo2}, }
}
It's curious because I use no inheritance in my_module::internal,
no require etc. and despite that I can access to the variables of
my_module. Is it normal?
It is very poor form to access $my_module::params::foo1 and
$my_module::params::foo2 via inheriting class my_module (i.e. as
${my_module::foo1}, etc.). With that out of the way, it is better to say
that the result you observe is among the valid possibilities than to say it
is normal.
All class variables have global visibility regardless of inheritance or
declaration (e.g. via include / require). The main purpose of all that *as
it pertains to variables* is to ensure that Puppet evaluates classes during
catalog compilation in an order that assigns values to those variables
before those values are used. It also serves a documentary purpose,
showing clearly that one class has a dependency on another.
One thing very curious too: in the my_module::internal class
I can access to $var1 with this syntax :
${my_module::var1}
No, you can't. There is no $var1 in class my_module::internal, so you are
not accessing such a variable. You are instead accessing
$my_module::params::var1 via an alias (that alias resulting from class
my_module inheriting my_module::params). Don't use that alias, even in
class my_module.
and $var1 is empty. Ok, I think I understand that. But in my
template test_internal.txt.erb I can use directly:
blabla %= @var1 % blabla
without the fully qualified name. Here, I don't understand.
I don't believe you. That form of reference would work of class
my_module::internal were inheriting my_module::params (or class my_module)
because of the aliasing mechanism I described. It would also work if
my_module::internal had a parameter or an ordinary variable of its own
named var1. It will not work with the code you actually presented.
Anyway, although I do not understand well the scope mechanism
etc. I feel that I can just use this design for inner classes :
class my_module::internal {
# No inheritance, no require of my_module::params etc.
# It's unnecessary.
No, not a safe assumption.
# In the class, I must use the fully qualified name
# to access to a variable of my_module inherited by
# my_module::params (and sometimes overwritten).
# For instance:
notify { 'm1': message = var1 = ${my_module::var1}, }
Yes and no. Do always use fully-qualified names to reference variables of
other classes, even if you inherit from their classes. Do not reference
class variables via inheritance-related aliases, however. To some extent
those are requirements, and to some extent just good practices.
# But in templates, I can directy use @var1.
Only if there is a global or local variable with that name in the scope
from which the template is evaluated.
}
Am I wrong?
I'm afraid so, as described already above.
John
--
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/96c0b88f-6a17-4bd4-98be-30d4b6920dbd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
Thank you for your answer.
Le 17/09/2014 17:12, jcbollinger a écrit :
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
) inherits my_module::params {
include my_module
There's no point to including class my_module inside its own definition.
Did you mean to include my_module::internal?
Yes exactly. Sorry for the mistake.
class my_module::internal {
file { '/tmp/test_internal.txt':
content = template('test/test_internal.txt.erb'),
}
notify { 'm1': message = var1 = ${my_module::var1}, }
notify { 'm2': message = var2 = ${my_module::var2}, }
notify { 'm3': message = foo1 = ${my_module::foo1}, }
notify { 'm4': message = foo2 = ${my_module::foo2}, }
}
It's curious because I use no inheritance in my_module::internal,
no require etc. and despite that I can access to the variables of
my_module. Is it normal?
It is very poor form to access $my_module::params::foo1 and
$my_module::params::foo2 via inheriting class my_module (i.e. as
${my_module::foo1}, etc.).
But the my_module::internal inherits no class, so doesn't inherit
my_module class? I don't see where is the inheritance in the code
above.
Or, if I understand well, when I have:
class my_module {
include my_module::internal
}
I can say: my_module::internal inherits my_module. Is that correct?
With that out of the way, it is better to say
that the result you observe is among the valid possibilities than to say it
is normal.
All class variables have global visibility regardless of inheritance or
declaration (e.g. via include / require).
Do you mean that with:
class my_module {
include my_module::internal
}
In the body of my_module::internal class I can access to the variables
defined in my_module class? With a unqualified name?
The main purpose of all that *as
it pertains to variables* is to ensure that Puppet evaluates classes during
catalog compilation in an order that assigns values to those variables
before those values are used. It also serves a documentary purpose,
showing clearly that one class has a dependency on another.
One thing very curious too: in the my_module::internal class
I can access to $var1 with this syntax :
${my_module::var1}
No, you can't. There is no $var1 in class my_module::internal, so you are
not accessing such a variable. You are instead accessing
$my_module::params::var1 via an alias (that alias resulting from class
my_module inheriting my_module::params). Don't use that alias, even in
class my_module.
Ok.
and $var1 is empty. Ok, I think I understand that. But in my
template test_internal.txt.erb I can use directly:
blabla %= @var1 % blabla
without the fully qualified name. Here, I don't understand.
I don't believe you.
I can give you a precise and quick (if you have already a Debian Wheezy)
process to reproduct this. I take a Debian Wheezy, updated and cleaned
(it's a simple VM in Virtualbox). And here is the process:
---
# Quick install of puppetmaster
root@wheezy-clean:~# wget
https://apt.puppetlabs.com/puppetlabs-release-$(lsb_release -sc).deb
root@wheezy-clean:~# dpkg -i puppetlabs-release-$(lsb_release -sc).deb
root@wheezy-clean:~# apt-get update
root@wheezy-clean:~# apt-get install puppetmaster
# I use puppet version 3.7.1
root@wheezy-clean:~# puppet -V
3.7.1
# In [main] section, I just:
#1. comment this line - #templatedir=$confdir/templates (deprecated)
#2 add this line - environmentpath = $confdir/environments
root@wheezy-clean:~# vim /etc/puppet/puppet.conf
root@wheezy-clean:~# cd /etc/puppet/environments/
root@wheezy-clean:/etc/puppet/environments# ls -l
total 4
drwxr-xr-x 4 root root 4096 Sep 18 04:35 example_env
# I create my conf (modules etc. in production directory)
# It's very basic. You can see my conf here
http://sisco.laf.free.fr/divers/production.tar.gz
root@wheezy-clean:/etc/puppet/environments# wget
http://sisco.laf.free.fr/divers/production.tar.gz
root@wheezy-clean:/etc/puppet/environments# tar -xf production.tar.gz
root@wheezy-clean:/etc/puppet/environments# rm production.tar.gz
root@wheezy-clean:/etc/puppet/environments# ls -l
total 8
drwxr-xr-x 4 root root 4096 Sep 18 04:35 example_env
drwxr-xr-x 4 1000 1000 4096 Sep 18 03:43 production
root@wheezy-clean:/etc/puppet/environments# apt-get install tree
# In ./manisfests/site.pp you'll can see that I just include
# the profile::test class.
# In ./modules/profiles/manifests/test.pp, I just declare
# the ::test class with one parameter
# And I think the test module will very easy to understand.
root@wheezy-clean:/etc/puppet/environments# tree production/
production/
├── manifests
│ └── site.pp
└── modules
├── profiles
│ └── manifests
│ └── test.pp
└── test
├── manifests
│ ├── init.pp
│ ├── internal.pp
[Puppet Users] About the params pattern
Hi,
About the params pattern, I had read this article :
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/
Suppose I want to use the params pattern in my modulees (ok there
really is no *better* way but imagine I want to use this way). In
the article, the author explains that, for the top level class of
my module, I can use this way :
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
...
) inherits my_module::params {
# The body of the class
}
Ok, I understand that. But what about an internal class of my module?
If I want to define an internal class (my_module/internal.pp) which
will be declared in the my_module class, what is the best way?
In the internal class, I want probably to use some parameters of
the my_module class and some variables of the my_module::params
class. How can I do that? Like below? I have doubts because in this
cas I have lot of inheritance and I understand that it was not a
good thing.
# Definition of the my_module::internal class
# I need to the value of $var2 and $var3 of he top level class my_module
# and I need to parameters in my_module::params.
class my_module::internal (
$var2,
$var3,
) inherits my_module::params {
# The body of the class
}
# Declaration of my_module::internal class in the my_module class
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
...
) inherits my_module::params {
# The body of the class
class my_module::internal {
var2 = $var2,
var3 = $var3,
}
}
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5418CF25.8070101%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] About the params pattern
As far as I know inner classes are an anti pattern(for the lack of a
better term)
Each class should live in its own file.
More than one class per file is discouraged
On Sep 16, 2014 7:00 PM, Francois Lafont francois.lafont.1...@gmail.com
wrote:
Hi,
About the params pattern, I had read this article :
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/
Suppose I want to use the params pattern in my modulees (ok there
really is no *better* way but imagine I want to use this way). In
the article, the author explains that, for the top level class of
my module, I can use this way :
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
...
) inherits my_module::params {
# The body of the class
}
Ok, I understand that. But what about an internal class of my module?
If I want to define an internal class (my_module/internal.pp) which
will be declared in the my_module class, what is the best way?
In the internal class, I want probably to use some parameters of
the my_module class and some variables of the my_module::params
class. How can I do that? Like below? I have doubts because in this
cas I have lot of inheritance and I understand that it was not a
good thing.
# Definition of the my_module::internal class
# I need to the value of $var2 and $var3 of he top level class
my_module
# and I need to parameters in my_module::params.
class my_module::internal (
$var2,
$var3,
) inherits my_module::params {
# The body of the class
}
# Declaration of my_module::internal class in the my_module class
class my_module (
$var1 = $my_module::params::var1,
$var2 = $my_module::params::var2,
$var3 = $my_module::params::var3,
...
) inherits my_module::params {
# The body of the class
class my_module::internal {
var2 = $var2,
var3 = $var3,
}
}
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5418CF25.8070101%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.
--
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/CAApMPgy-7Ab%2Bsw5DZwNc3PQh2xtn%2BxiCC%3DEs5PB-XOpT06pY2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
