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

Search Discussions

  • Jo Rhett at Feb 11, 2013 at 9:49 pm
    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.
  • Roman Shaposhnik at Feb 11, 2013 at 10:03 pm

    On Mon, Feb 11, 2013 at 1:49 PM, Jo Rhett 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.
  • Jcbollinger at Feb 11, 2013 at 11:06 pm

    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 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.
  • Roman Shaposhnik at Feb 12, 2013 at 5:28 pm

    On Mon, Feb 11, 2013 at 3:06 PM, jcbollinger 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.
  • Jcbollinger at Feb 12, 2013 at 8:57 pm

    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.
  • Roman Shaposhnik at Feb 25, 2013 at 4:48 am

    On Tue, Feb 12, 2013 at 12:50 PM, jcbollinger 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 11, '13 at 5:37p
activeFeb 25, '13 at 4:48a
posts7
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase