[Puppet Users] Is paramater ordering non-deterministic?
I've run into the following issue with parameters that are dependent on
each other. Suppose I have the following class:
class foo(
$owner,
$prefix = /opt/${owner},
$etc_dir = ${prefix}/etc
) {
file{${etc_dir}:
ensure = directory,
owner = $owner,
group = $owner,
mode = 0660,
...
}
The order that the parameters are defined appears to be non-deterministic,
so that sometimes $etc_dir is defined before $prefix. Which means that $etc
is set to '/etc', and of course, this restricts the permissions on /etc,
which breaks the server (including preventing any user, including root,
from sudoing!). Fortunately, this was found while testing manifests on
disposable virtual machines. I shudder to think what would have happened if
we didn't figure out the cause and deployed this on actual servers.
So, am I correct in assuming that the order of parameter setting is
non-deterministic (and so should avoid setting them like above), or is
there something else going on?
If parameter order is not deterministic, I do think it should be explicitly
documented, with a warning about what can go wrong. (Apologies if I've been
daft and missed an existing mention of this somewhere.)
FWIW, I added a note to http://projects.puppetlabs.com/issues/4408 about
this issue.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/AjNp3Hlh8woJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Is paramater ordering non-deterministic?
The evaluation order of the parameters is not deterministic as I learned
when implementing validation of references in Geppetto. (BTW, Geppetto
issues warnings/errors when trying to reference potentially
uninitialized variables as in your example).
You need to move the logic computing the resulting defaults inside the
class to be able to use the $owner and $prefix values.
Regards
- henrik
On 2012-16-04 12:39, Robert Rothenberg wrote:
I've run into the following issue with parameters that are dependent on
each other. Suppose I have the following class:
| class foo(
$owner,
$prefix = /opt/${owner},
$etc_dir = ${prefix}/etc
) {
file{${etc_dir}:
ensure = directory,
owner = $owner,
group = $owner,
mode = 0660,
...
}|
The order that the parameters are defined appears to be
non-deterministic, so that sometimes $etc_dir is defined before $prefix.
Which means that $etc is set to '/etc', and of course, this restricts
the permissions on /etc, which breaks the server (including preventing
any user, including root, from sudoing!). Fortunately, this was found
while testing manifests on disposable virtual machines. I shudder to
think what would have happened if we didn't figure out the cause and
deployed this on actual servers.
So, am I correct in assuming that the order of parameter setting is
non-deterministic (and so should avoid setting them like above), or is
there something else going on?
If parameter order is not deterministic, I do think it should be
explicitly documented, with a warning about what can go wrong.
(Apologies if I've been daft and missed an existing mention of this
somewhere.)
FWIW, I added a note to http://projects.puppetlabs.com/issues/4408 about
this issue.
--
You received this message because you are subscribed to the Google
Groups Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/AjNp3Hlh8woJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups Puppet
Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Is paramater ordering non-deterministic?
So will the setting of the values for $owner and $prefix be deterministic,
when set inside a class or resource definition?
Also, what if I want to be able to override these with user settings?
(That's one of the reasons that they are parameters in the first place.)
On Monday, April 16, 2012 2:14:36 PM UTC+1, Henrik Lindberg wrote:
The evaluation order of the parameters is not deterministic as I learned
when implementing validation of references in Geppetto. (BTW, Geppetto
issues warnings/errors when trying to reference potentially
uninitialized variables as in your example).
You need to move the logic computing the resulting defaults inside the
class to be able to use the $owner and $prefix values.
Regards
- henrik
On 2012-16-04 12:39, Robert Rothenberg wrote:
I've run into the following issue with parameters that are dependent on
each other. Suppose I have the following class:
| class foo(
$owner,
$prefix = /opt/${owner},
$etc_dir = ${prefix}/etc
) {
file{${etc_dir}:
ensure = directory,
owner = $owner,
group = $owner,
mode = 0660,
...
}|
The order that the parameters are defined appears to be
non-deterministic, so that sometimes $etc_dir is defined before $prefix.
Which means that $etc is set to '/etc', and of course, this restricts
the permissions on /etc, which breaks the server (including preventing
any user, including root, from sudoing!). Fortunately, this was found
while testing manifests on disposable virtual machines. I shudder to
think what would have happened if we didn't figure out the cause and
deployed this on actual servers.
So, am I correct in assuming that the order of parameter setting is
non-deterministic (and so should avoid setting them like above), or is
there something else going on?
If parameter order is not deterministic, I do think it should be
explicitly documented, with a warning about what can go wrong.
(Apologies if I've been daft and missed an existing mention of this
somewhere.)
FWIW, I added a note to http://projects.puppetlabs.com/issues/4408 about
this issue.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/r2OAYubbE-oJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Is paramater ordering non-deterministic?
On Mon, Apr 16, 2012 at 6:22 AM, Robert Rothenberg rob...@gmail.com wrote: So will the setting of the values for $owner and $prefix be deterministic, when set inside a class or resource definition? Yes. The issue with parameters in class declaration is described in further details here: http://projects.puppetlabs.com/issues/9848 Also, what if I want to be able to override these with user settings? (That's one of the reasons that they are parameters in the first place.) John's example works with the edge case where you actually want to set a variable to '', you'll see our documentation list 'UNSET' as the default for this reason: http://docs.puppetlabs.com/guides/parameterized_classes.html Thanks, Nan -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
