Puppet users - Feb 2013 - Alternatives to a dynamic scope lookup

Hi!

now that dynamic scope lookup is going away, I''m looking
for a good alternative for the following use case: suppose
I have a set of classes that all set up a pretty rich internal
state with quite a few variables defined in their namespace.
On top of that all of them need to do a common set of steps.

Previously I''d capture that set of steps into a custom define
that would server a purpose of a macro:

define this_is_really_a_macro {
  notify { "$var1 ... $varN": }
}

and then ''expand'' that macro inside of each of the classes

  class foo {
      $var1 = ...
      ....
      this_is_really_a_macro { "macro 1": }
  }
  ....

Then, because of the dynamic scope lookup everything would
work just fine.

Question: what''s the recommended way of migrating to
Puppet 3.X+ world here?

Thanks,
Roman.

-- 
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+unsubscribe@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.

From the snippet you posted, I don''t see why you can''t pass
$var1 into the define. No magic, just straightforward variable passing, right?

On Feb 11, 2013, at 9:31 AM, Roman Shaposhnik wrote:
> now that dynamic scope lookup is going away, I''m looking
> for a good alternative for the following use case: suppose
> I have a set of classes that all set up a pretty rich internal
> state with quite a few variables defined in their namespace.
> On top of that all of them need to do a common set of steps.
> 
> Previously I''d capture that set of steps into a custom define
> that would server a purpose of a macro:
> 
> define this_is_really_a_macro {
>  notify { "$var1 ... $varN": }
> }
> 
> and then ''expand'' that macro inside of each of the
classes
> 
>  class foo {
>      $var1 = ...
>      ....
>      this_is_really_a_macro { "macro 1": }
>  }
>  ....
> 
> Then, because of the dynamic scope lookup everything would
> work just fine.
> 
> Question: what''s the recommended way of migrating to
> Puppet 3.X+ world here?
> 
> Thanks,
> Roman.
> 
> -- 
> 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+unsubscribe@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.
> 
> 
-- 
Jo Rhett
Net Consonance : net philanthropy to improve open source and internet projects.



-- 
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+unsubscribe@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.

On Mon, Feb 11, 2013 at 1:49 PM, Jo Rhett <jrhett@netconsonance.com>
wrote:
> From the snippet you posted, I don''t see why you can''t
pass $var1 into the
> define. No magic, just straightforward variable passing, right?
Sure thing. The trouble is that as I said -- there''s *quite* a rich
state
that these classes create. So it is not a single var we''re talking
about
but a dozen or so.

Now, one could argue that it makes things more explicit if I actually
have to tediously pass them explicitly. Personally, I fear it may increase
the chance of typos.

As I said -- what I''m asking here is literally a #define as it is known
in C.
There''s a bunch of code that I need to be ''pasted'' in
a couple of different
places and I''m wondering whether there''s a language construct
that
could help me.

And when I say ''pasted'' -- I do mean it.
''Pasted'' as in ''dumb preprocessor
pasted kind of way'' ;-)

Thanks,
Roman.

-- 
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+unsubscribe@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.

On Monday, February 11, 2013 4:03:24 PM UTC-6, Roman Shaposhnik
wrote:
>
> On Mon, Feb 11, 2013 at 1:49 PM, Jo Rhett
<jrh...@netconsonance.com<javascript:>>
> wrote: 
> > From the snippet you posted, I don''t see why you
can''t pass $var1 into
> the 
> > define. No magic, just straightforward variable passing, right? 
>
> Sure thing. The trouble is that as I said -- there''s *quite* a
rich state
> that these classes create. So it is not a single var we''re talking
about
> but a dozen or so. 
>
> Now, one could argue that it makes things more explicit if I actually 
> have to tediously pass them explicitly. Personally, I fear it may increase 
> the chance of typos. 
>
> As I said -- what I''m asking here is literally a #define as it is
known in
> C. 
> There''s a bunch of code that I need to be
''pasted'' in a couple of
> different 
> places and I''m wondering whether there''s a language
construct that
> could help me. 
>

Puppet DSL does not have such a feature.

You have at least three alternatives:

   1. As Jo said, give the definition all the formal parameters it needs to 
   specify its data
   2. Split it into multiple, similar defines that each pull some of their 
   data from the appropriate (presumably different) class variables
   3. Depending on how your classes are arranged, hiera may provide a 
   reasonable way to address this problem.  (Notwithstanding your distinct 
   lack of enthusiasm about hiera in your other thread.)

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+unsubscribe@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.

On Mon, Feb 11, 2013 at 3:06 PM, jcbollinger <John.Bollinger@stjude.org>
wrote:
> Puppet DSL does not have such a feature.
:-(
> You have at least three alternatives:
>
> Depending on how your classes are arranged, hiera may provide a reasonable
> way to address this problem.  (Notwithstanding your distinct lack of
> enthusiasm about hiera in your other thread.)
As I said in that other thread -- my only prejudice against Hiera is that
it *feels* heavyweight for what I''m trying to accomplish. If, however,
you
guys can help me understand all the options a little bit better it is very
much possible that I would come back from the discussion with a feeling
that Hiera is the best tool for the job regardless of my initial assessment.
Once again -- your help is greatly appreciated!

Now, to a practical matter -- in this particular case (unlike the
other thread :-))
I genuinely don''t see how I can utilize Hiera. Given that the classes
create
the rich state based on facter values/etc (e.g.:
    if ($::this == ''that'') {
       $var1 = ''something''
    } else {
        ....
    }
)  I am not sure how can I map that into hiera.

I''d welcome suggestions of re-architecting the class hierarchy, but I
need
a bit more practical advice.

Thanks,
Roman.

-- 
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+unsubscribe@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.

On Tuesday, February 12, 2013 11:28:28 AM UTC-6, Roman Shaposhnik
wrote:
>
> Now, to a practical matter -- in this particular case (unlike the 
> other thread :-)) 
> I genuinely don''t see how I can utilize Hiera. Given that the
classes
> create 
> the rich state based on facter values/etc (e.g.: 
>     if ($::this == ''that'') { 
>        $var1 = ''something'' 
>     } else { 
>         .... 
>     } 
> )  I am not sure how can I map that into hiera. 
>

It might not be feasible to do so.  There are some Puppet data issues that 
Hiera does not solve.  What I was thinking of, however, is the fact that 
you can make levels of your hiera hierarchy dependent on the class or 
module requesting data.  That wouldn''t directly address the question
you
posed, but it might suggest an alternative approach that solves your 
problem.


> I''d welcome suggestions of re-architecting the class hierarchy,
but I need
> a bit more practical advice. 
>

The term "class hierarchy" sets my Puppet radar ringing.  Despite some
appearances to the contrary, Puppet''s is not an OO language, and it is 
likely to cause you great consternation if attempt to use it as if it were 
one.  Puppet does have hierarchical namespaces, and it does have 
subclassing (though its significance is very different than in, say, C++), 
but it is not typically advisable or useful to build deep or wide "class 
hierarchies" of sub and superclasses in Puppet.

I am open to the idea of offering architectural advice, but I don''t
have
either sufficient understanding of your requirements or sufficient 
understanding of your current code to offer any at this point.  As for 
practical advice on your present question, you already have most of what I 
can give you.  Basically, either have the definition receive the needed 
data via its parameters, or split it into multiple, more narrowly-purposed 
definitions, unless you happen to see a fit with Hiera.


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+unsubscribe@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.

On Tue, Feb 12, 2013 at 12:50 PM, jcbollinger <John.Bollinger@stjude.org>
wrote:
> I am open to the idea of offering architectural advice, but I
don''t have
> either sufficient understanding of your requirements or sufficient
> understanding of your current code to offer any at this point.  As for
> practical advice on your present question, you already have most of what I
> can give you.  Basically, either have the definition receive the needed
data
> via its parameters, or split it into multiple, more narrowly-purposed
> definitions, unless you happen to see a fit with Hiera.
Just to close the loop on the public ML: thanks to John and a few
other folks we''re now pursuing a full re-architecting of the
Bigtop''s
puppet code. All the interested parties can keep track of our
efforts over here (you can subscribe yourself to wiki updates):
   
https://cwiki.apache.org/confluence/display/BIGTOP/Next+generation+Puppet+code+for+Bigtop+deployment

Hopefully the outcome of this exercise will be useful not only
to the Apache Bigtop, but to the bigger pupper user community
as well.

Thanks,
Roman.

-- 
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+unsubscribe@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.