> As far as I am aware, resource defaults still affect the dynamic scope in 
> which they are declared, just as they always have done.  The guide to which 
> you referred seems to say that, too.  That means that the defaults you 
> declare in class 'mongo' apply to all resources declared in that class and in 
> any classes declared by that class, recursively, modulo parse-order issues 
> where the same class is declared in different places.
> 
> In your particular case, that means the File defaults you declare in class 
> 'mongo' apply in class mongo::repos (which is declared by class mongo) and 
> within the defined type instances declared therein.

That's what I was figuring must be happening.  As dig deeper, I keep trying to 
get to a better place in my head w/ regard to scoping.   It's… interesting 
sometimes :)


>  
> 
> class mongo::repos {
>   repos{"10gen":} } 
> You really should use the fully-qualified name of that defined type.  I 
> suppose it must be "mongo::repos::repos".  Aside from being safer, it would 
> be much clearer.

Actually, the defined type is in it's own module, repos.   It's the only thing 
in there, and thus, this would be it's FQN, wouldn't it ?

 Class mongo::repos only exists to call it, and move the   repos{"10gen":} into 
another stage.   I couldn't see a way to do it any other way when I initially 
set this up.
That was the entirety of the mongo::repos class.



> Anyway, If you don't want class 'mongo's file defaults to apply in this scope 
> then you could try overriding them here:
> 
> File {
>   require => undef
> }
> 
> Alternatively, the file resource(s) declared by mongo::repos::repos can do 
> the same thing individually.
>  
> 
> Best, though, might be to refactor class 'mongo' so that the scope of the 
> resource defaults does not include class mongo::repos in the first place.  
> For example:
> 
> class mongo($repl_set = undef) {
>   class { 'mongo::repos': stage => 'first' }
>   class { 'mongo::everything_else': }
> }
> 

And that's the way that feels right.    The undef option is hacky.  The 
refactor seems to be the more clear & elegant.   


So in summary:  3 total hacks,   1 better  answer.


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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to