FAQ
Hi,
a question regarding combining *inherit* and *include*: I have variable(s)
defined in a father class and child classes should access these - but there
should always be the possibility to override the default value. Let's
assume this scenario:

There's a module "module_x" and these directories:
$moduledir/module_x/manifests/ and there's an "init.pp" with this content:

class module_x {
$var = 'value'

include module_x::child
include module_x::another_child
include module_x::another_child2
include module_x::another_child3
...
}


  Class "module_x::child" in file "child.pp" should be able to use "$var"
with its default value - but should also be allowed to override it. It
would look like this:

class module_x::child inherits module_x {
// wants to use a default value for $var but should be able to override it.
}


Question: Is there somehow a problem that class "child" inherits class
"module_x" *with all its many includes*?

Thanks in advance,
Christian

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

  • Jcbollinger at May 3, 2013 at 1:12 pm

    On Friday, May 3, 2013 4:16:25 AM UTC-5, christian...@gmail.com wrote:
    Hi,
    a question regarding combining *inherit* and *include*: I have
    variable(s) defined in a father class and child classes should access these
    - but there should always be the possibility to override the default value.
    Let's assume this scenario:

    There's a module "module_x" and these directories:
    $moduledir/module_x/manifests/ and there's an "init.pp" with this content:

    class module_x {
    $var = 'value'

    include module_x::child
    include module_x::another_child
    include module_x::another_child2
    include module_x::another_child3
    ...
    }


    Class "module_x::child" in file "child.pp" should be able to use "$var"
    with its default value - but should also be allowed to override it.

    Subclasses can never 'override' ancestor class variables. They can
    partially *hide* them within their own scope by declaring a same-named
    local variable, but that has no effect on what the parent class or any
    other sees as the value of the parent-class variable.

    The purpose of class inheritance in Puppet is to permit overriding of *resource
    parameters* of resources declared by the parent class. It has a
    sometimes-useful side effect of causing the parent class to be evaluated
    before any part of the child class, notably including the child class's
    parameter list, if any. If you're using class inheritance for any other
    purpose then you are misusing it (and it is probably not doing what you
    think it's doing).


    It would look like this:

    class module_x::child inherits module_x {
    // wants to use a default value for $var but should be able to override it.
    }

    That creates a circular evaluation dependency: class module_x must be
    evaluated before class module_x::child (because the latter inherits the
    former), but class 'module_x::child' must be evaluated as the first step in
    evaluating class module_x (on account of 'include'ing it). I'm not sure
    what Puppet will actually do with that, but it's fundamentally wrong.


    Question: Is there somehow a problem that class "child" inherits class
    "module_x" *with all its many includes*?
    There is a problem that class module_x::child inherits class module_x with
    its specific include of class module_x::child. I see no reason why any of
    the other includes would be an issue.

    You have a fundamental problem with your design approach. It will not work
    as you envision, so you need to take a step back and devise a new way to go
    about it. If you explain better what you are trying to achieve then we may
    be able to help you more.


    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.
  • Christian Le Flamm at May 10, 2013 at 2:53 pm
    Thx, maybe this was a little too straight from the hip... BTW: I've tried
    it - it even worked... but I see that's probably caused by a lot of strange
    luck...

    Subclasses can never 'override' ancestor class variables. They can
    partially *hide* them within their own scope by declaring a same-named
    local variable, but that has no effect on what the parent class or any
    other sees as the value of the parent-class variable.
    Interesting objection - that's actually what I meant saying "override".
    Let's try something else: There's a module "module_x" and these
    directories: $moduledir/module_x/manifests/ and there's an "init.pp" with
    this content:

        class module_x {
         include module_x::child
    include module_x::another_child
    include module_x::another_child2
    include module_x::another_child3
    ...
        }

    There's also a file 'constant.pp' containing this

         class module_x::constant {
             $var = 'value'
         }

    Class module_x::constant is not included. Classes like module_x::child
    should be able to inherit the default value of $var but also be able to
    hide it within their own scope by declaring a same-named local variable. It
    would look like this:

    class module_x::child inherits module_x::constant {
    // wants to use a default value for $var but should be able to hide it
    within their own scope.
    }


    Something wrong with that?

    --
    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.
  • Christian Le Flamm at May 10, 2013 at 2:54 pm
    Sorry, wasn't able to format it properly... formatting it had no effect.

    --
    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 May 10, 2013 at 5:57 pm

    On Friday, May 10, 2013 9:53:39 AM UTC-5, christian...@gmail.com wrote:
    Thx, maybe this was a little too straight from the hip... BTW: I've tried
    it - it even worked... but I see that's probably caused by a lot of strange
    luck...

    Subclasses can never 'override' ancestor class variables. They can
    partially *hide* them within their own scope by declaring a same-named
    local variable, but that has no effect on what the parent class or any
    other sees as the value of the parent-class variable.
    Interesting objection - that's actually what I meant saying "override".
    Let's try something else: There's a module "module_x" and these
    directories: $moduledir/module_x/manifests/ and there's an "init.pp" with
    this content:

    class module_x {
    include module_x::child
    include module_x::another_child
    include module_x::another_child2
    include module_x::another_child3
    ...
    }

    There's also a file 'constant.pp' containing this

    class module_x::constant {
    $var = 'value'
    }

    Class module_x::constant is not included. Classes like module_x::child
    should be able to inherit the default value of $var but also be able to
    hide it within their own scope by declaring a same-named local variable.
    It would look like this:

    class module_x::child inherits module_x::constant {
    // wants to use a default value for $var but should be able to hide it
    within their own scope.
    }


    Something wrong with that?

    There is nothing inherently wrong with it. There is only a question of
    whether it means what you want it to mean. There are two main questions to
    consider:

        1. in any given context of interest, what does the unqualified variable
        reference $var mean?
        2. what does (for example) $module_x::child::var mean?

    Suppose you have this version of module_x::child:

    class module_x::child inherits module_x::common {
       # no local declaration of variable $var
    }

    Then,

        - in class module_x::child, $var resolves to $module_x::common::var, and
        - variable $module_x::child::var is undefined (everywhere)

    On the other hand, if module_x::child looks like this:

    class module_x::child inherits module_x::common {
       $var = 'my value'
    }

    then,

        - in class module_x::child, $var resolves to $module_x::child::var, and
        - variable $module_x::child::var is defined (everywhere, subject to
        parse order), and has the specified value, which may or may not differ from
        the value of $module_x::common::var

    Classes other than module_x::child and any others that inherit from it see
    no difference between the two cases.


    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.
  • Jcbollinger at May 10, 2013 at 6:00 pm

    On Friday, May 10, 2013 12:57:40 PM UTC-5, jcbollinger wrote:
    Classes other than module_x::child and any others that inherit from it see
    no difference between the two cases.
    Sorry, that's too broad. Other classes don't see any effect on the meaning
    of $var or of $module_x::common::var. They do see a difference in the
    meaning of $module_x::child::var, as I described.


    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 3, '13 at 9:16a
activeMay 10, '13 at 6:00p
posts6
users2
websitepuppetlabs.com

2 users in discussion

Jcbollinger: 3 posts Christian Le Flamm: 3 posts

People

Translate

site design / logo © 2022 Grokbase