On Nov 4, 7:20 am, Baptiste Grenier <[email protected]>
wrote:
> Hello,
>
> Le 03/11/11 15:45, jcbollinger t l scripta :
[...]
> > 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...


For the record, that is not an implementation of my recommendation.
It is not safe for class sudo::apdater to include that new class,
except in the most technical of senses.

The point is to have a source of truth separate from apdater::client
for that class and class sudo both to draw on, but you have that
relationship reversed on one side.  That just lengthens the dependency
chain you already had (now sudo depends on newclass depends on
apdater::client), which doesn't gain you anything.  For this to work
you need {sudo, apdater::client} depends on newclass.

Replace "newclass" with "global variable" or "external data" as you
like.


> > 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.


Whatever logic you use now either to set $sudo_allow_aptdater_user or
to choose whether to include class apdater::client can certainly be
put in a separate class.  Depending on what the logic is, it might be
ugly / unmaintainable / painful to move it there, but not impossible.


> 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 am glad you have found a solution.


Good luck,

John

-- 
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.

Reply via email to