FAQ
Hello

I have some code that works like the simplified clase shown below. The idea
is to have a define "foo" that includes a class "foo::pre" which contains
resources that need to be executed before the define is called. The define
can be called multiple times but the initialization has to be done only
once, which is why it's implemented as a class:

class foo::pre {
notice("foo::pre")
}
define foo() {
include 'foo::pre'
notice("foo")
}
class x {
notice("x")
foo { 'x foo':
}
}
class y {
notice("y")
foo { 'y foo':
}
}
include x
include y

The issue is that now I need to parametrize foo::pre so that its behavior
depends on a variable that exists in foo:

class foo::pre($blah) {
notice("foo::pre")
}
define foo() {
class { 'foo::pre':
blah => 1,
}
notice("foo")
}
class x {
notice("x")
foo { 'x foo':
}
}
class y {
notice("y")
foo { 'y foo':
}
}
include x
include y

With this code I get "Duplicate definition: Class[Foo::Pre] is already
defined". This seems weird to me because I thought the "class { 'myclass':
}" syntax was semantically equivalent to "include myclass". Puppet,
however, complains that it's being defined twice, even though there's no
definition happening there, just inclusion.

So, is there a way to redesign this to match the original behavior? I know
the current trend is to keep this kind of thing in hiera but this is
already a fairly large code base that can't be changed quickly...

Thanks in advance,
Andre

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/dll5ilVD_60J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Jcbollinger at Apr 27, 2012 at 12:58 pm

    On Apr 27, 6:40 am, Andre Nathan wrote:
    Hello

    I have some code that works like the simplified clase shown below. The idea
    is to have a define "foo" that includes a class "foo::pre" which contains
    resources that need to be executed before the define is called. The define
    can be called multiple times but the initialization has to be done only
    once, which is why it's implemented as a class:

    class foo::pre {
    notice("foo::pre")}

    define foo() {
    include 'foo::pre'
    notice("foo")}

    class x {
    notice("x")
    foo { 'x foo':
    }}

    class y {
    notice("y")
    foo { 'y foo':
    }}

    include x
    include y

    Great, no problem.

    The issue is that now I need to parametrize foo::pre so that its behavior
    depends on a variable that exists in foo:

    class foo::pre($blah) {
    notice("foo::pre")}

    define foo() {
    class { 'foo::pre':
    blah => 1,
    }
    notice("foo")}

    class x {
    notice("x")
    foo { 'x foo':
    }}

    class y {
    notice("y")
    foo { 'y foo':
    }}

    include x
    include y

    With this code I get "Duplicate definition: Class[Foo::Pre] is already
    defined". This seems weird to me because I thought the "class { 'myclass':}" syntax was semantically equivalent to "include myclass". Puppet,

    however, complains that it's being defined twice, even though there's no
    definition happening there, just inclusion.

    This is one of the several drawbacks of Puppet's implementation of
    parameterized classes. It may be that "class { 'myclass':}" is
    semantically equivalent to "include 'myclass'", but that's beside the
    point. Unlike ordinary classes, parameterized classes can only be
    included / declared once. It's not necessarily the declaration syntax
    that makes the difference, but rather the nature of the class being
    declared.

    So, is there a way to redesign this to match the original behavior? I know
    the current trend is to keep this kind of thing in hiera but this is
    already a fairly large code base that can't be changed quickly...

    I know it's not what you want to hear, but Hiera is your best bet. I
    don't think the code base size is relevant, because I don't think the
    time and effort to implement an Hiera-based class data source is
    likely to differ much from what parameterizing all the same classes
    would require. Or to put it a different way, solving your problem via
    class parameterization would require *at least* as much shakeup of
    your code base as would implementing an hiera-based solution.

    If you insist on using parameterized classes, then you have to come up
    with a way to ensure that they are declared exactly once if they are
    needed. If it is harmless to declare them when they are unneeded,
    then you could declare them unconditionally for every node; otherwise
    you have a mess to sort out. It is my impression that people with
    that sort of mess usually end up relying on a complex ENC to deal with
    it.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Andre Nathan at Apr 27, 2012 at 1:12 pm
    Hello John
    On Friday, April 27, 2012 9:58:09 AM UTC-3, jcbollinger wrote:

    I know it's not what you want to hear, but Hiera is your best bet. I
    don't think the code base size is relevant, because I don't think the
    time and effort to implement an Hiera-based class data source is
    likely to differ much from what parameterizing all the same classes
    would require. Or to put it a different way, solving your problem via
    class parameterization would require *at least* as much shakeup of
    your code base as would implementing an hiera-based solution.
    Well, the thing is that we're in the middle of a transition process that is
    moving from "everything is a global variable in the node" to parametrized
    classes, and while they are not perfect, I found that our new code is much
    saner and easier to debug when using them.

    So the question is, are parametrized classes now considered "deprecated"? I
    remember reading somewhere that improvements were being made for Puppet
    2.8... While I can see the advantages of Hiera, it seems to me that it's
    another instance of the global variable problem if it's used to load values
    inside some class, and I'd rather not lose the benefit of being able to
    check a class "signature" to see immediately what variables it needs, and
    having the code fail if any is not provided.

    Thanks,
    Andre

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/eA93Ge_3z2kJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Craig Dunn at Apr 27, 2012 at 1:23 pm

    to me that it's another instance of the global variable problem if it's
    used to load values inside some class, and I'd rather not lose the
    benefit of being able to check a class "signature" to see immediately
    what variables it needs, and having the code fail if any is not provided.
    If I'm understanding you right, then I get around that problem using the
    %{calling_module} variable passed from hiera-puppet.

    For example

    class foo::data ( $somevar = hiera("bar") ) {

    When used with a hierarchy similar to

    %{environment}/%{calling_module} in my

    Means I can store all my "foo" variables up into, for example, dev/foo.yaml

    It's a nice way to be able to see at-a-glance how "foo" is configured in
    my environment, and also helps with ambiguous variable names (eg: $port)
    as grouping them this way offers a kind of scope.

    Craig


    --
    Craig Dunn | http://www.craigdunn.org
    Yahoo/Skype: craigrdunn | Twitter: @crayfishX

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Jcbollinger at Apr 30, 2012 at 1:36 pm

    On Apr 27, 8:12 am, Andre Nathan wrote:
    Hello John
    On Friday, April 27, 2012 9:58:09 AM UTC-3, jcbollinger wrote:

    I know it's not what you want to hear, but Hiera is your best bet.  I
    don't think the code base size is relevant, because I don't think the
    time and effort to implement an Hiera-based class data source is
    likely to differ much from what parameterizing all the same classes
    would require.  Or to put it a different way, solving your problem via
    class parameterization would require *at least* as much shakeup of
    your code base as would implementing an hiera-based solution.
    Well, the thing is that we're in the middle of a transition process that is
    moving from "everything is a global variable in the node" to parametrized
    classes, and while they are not perfect, I found that our new code is much
    saner and easier to debug when using them.

    So the question is, are parametrized classes now considered "deprecated"?

    No, they are not deprecated. "Raw" would be a better description: the
    implementation of parameterized classes in 2.6 (where they were
    introduced) and 2.7 has always had problems, especially including the
    one you asked about.

    I
    remember reading somewhere that improvements were being made for Puppet
    2.8...

    I have it on good authority that parameterized classes will be greatly
    improved for Puppet's next major release, "Telly". I have been told
    that among other things, they will be integrated with Hiera in a way
    that sounds very useful. I am uncertain, however, whether the use
    case you seem to be looking for will be supported. That is, in Telly
    you should be able to include a parameterized class as many times as
    you want if you rely only on parameter defaults (which themselves will
    be improved for Telly), but I don't know whether you will be able to
    do the same if you specify custom parameter values.

    While I can see the advantages of Hiera, it seems to me that it's
    another instance of the global variable problem if it's used to load values
    inside some class, and I'd rather not lose the benefit of being able to
    check a class "signature" to see immediately what variables it needs, and
    having the code fail if any is not provided.

    I think you will like Telly's improvements in this area, at least if
    they work as was explained to me. Until then, however, you simply
    cannot use parameterized classes in the way you are trying to do. It
    does not work.

    Use external data from Hiera instead of class parameters, with Hiera
    keys corresponding to the class and parameter names that you otherwise
    would implement. That's a sane and manageable design in its own
    right, and it will also position you well to transition to Telly when
    it come out. Document your classes with plain comments (which you
    should do anyway), and you have most of what you were looking for,
    except Puppet automatically failing if a class parameter is omitted.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 27, '12 at 11:40a
activeApr 30, '12 at 1:36p
posts5
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase