Hello,
Le 03/11/11 à 15:45, jcbollinger téléscripta :
> On Nov 2, 9:57 am, Baptiste Grenier <[email protected]> wrote:
> > Le 31/10/11 16:09, jcbollinger t l scripta :
> > > On Oct 28, 10:07 am, Baptiste Grenier <[email protected]>
> > > wrote:
> > > You have an evaluation order problem, and you have tried to fix it
> > > by constraining the application order. Instead, you want something like
> > > this:
> >
> > > [...]
> >
> > > class sudo {
> > > # KEY CHANGE:
> > > include "aptdater::client"
> >
> > The problem is that I want to be able to include the sudo class without
> > including the aptdater::client class: some node can have sudo managed,
> > but won't be configured for apt-dater.
>
> There are several ugly ways you could do this. The clean way would be
> to pull the $aptdater::client::sudo_allow_aptdater_user variable out
> to a separate class that both class sudo and class aptdater::client
> can safely include (which implies that it is not parameterized),
I tried it quickly, with a test like this in the separate class:
-------------8<--------------------------------------------------------
if (inline_template("<%= classes.include?('aptdater::client') %>") == 'true')
{
$sudo_allow_aptdater_user = true
} else {
$sudo_allow_aptdater_user = false
}
-------------8<--------------------------------------------------------
But it still dependent of the order of the include of the classes...
> or to global scope,
I am already using global-scoped variable for a similar thing in another
module, but I am not too much satisfied with this approach, that's why I
tried other ways.
> or to external data loaded in both places via extlookup() or hiera.
I will also take a look at this possibility, thanks.
> If you're using an ENC then global scope is a good bet; otherwise
> external data is probably better.
We are not using an ENC for now, I will probably test external data.
> The separate class option is great, but it is distinct from the other
> two only if the new class can choose the variable's value based only
> on nodes' facts.
It does not seem to be possible for me.
By the way I was able to order the module application using run stages,
so thanks for pointing me to this direction.
I don't find this to be the perfect/cleanest solution for my problem,
but at least it is working as needed and expected :)
> > I could perhaps use a parametrized class like with something like an
> > aptdater_client_enabled paramter, but I don't find this very nice...
> > It's why I am trying to test a variable to see if aptdater::client is
> > enabled.
> It constitutes a class dependency for one class to rely on data
> belonging to another. If the former class must not directly or
> indirectly 'include' the latter, then it is inconsitent to have such a
> dependency at all.
Yes, I understand your point.
> Similarly, it is always a poor idea for a class to depend on whether
> a separate class has been included, which is the most fundamental
> data belonging to that class.
Yes, I saw that this leads to unedefined variable access which isn't
really clean.
I will see if I can think of a better way of doing this. (and taking in
account the time I have for this...)
> John
Thanks for your help!
Regards,
Baptiste
--
\,,/_[-_-]_\,,/
Finagle's Second Law:
No matter what the anticipated result, there will always be
someone eager to (a) misinterpret it, (b) fake it, or (c) believe it
happened according to his own pet theory.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
