FAQ
I have been following the various blog posts about the roles and
profiles pattern for classifying hosts, and I like it. It doesn't
provide a perfect fit for our infrastructure, but it is much better
than the ad-hoc classification we do now. I have a couple of
questions for those that use it, though:

1. Where are you putting your role classes and profile classes? A
role module and a profile module makes sense to me, but it seems like
something more tightly integrated with the Puppet DSL might be nice?

2. Assuming you have roles and profiles in modules, at what point do
you specify the parameters to your modules? I am particularly
interested in the answer to this question with regards to hiera. I
find that I want to add roles and profiles to the hiera hierarchy, and
I cannot come up with a way to do it.

I think if hiera supported lookup by the class containing the hiera
call, I could achieve what I want. For instance:

class profiles::oneofmyprofiles {
   include myparameterizedclass
}

I would like to have a hiera.yaml like so:

---
:backends:
   - yaml
:hierarchy:
   - nodes/%{::hostname}
   - profiles/%{class_name}
   - common
:yaml:
   :datadir: /etc/puppet/environments/%{environment}/data


Am I just completely off-base?

--
Chad M. Huneycutt

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

  • Brian Lalor at Feb 14, 2013 at 12:49 am
    Will this help? http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables

    --
    Brian Lalor
    blalor@bravo5.org
    On Feb 13, 2013, at 6:17 PM, Chad Huneycutt wrote:

    I have been following the various blog posts about the roles and
    profiles pattern for classifying hosts, and I like it. It doesn't
    provide a perfect fit for our infrastructure, but it is much better
    than the ad-hoc classification we do now. I have a couple of
    questions for those that use it, though:

    1. Where are you putting your role classes and profile classes? A
    role module and a profile module makes sense to me, but it seems like
    something more tightly integrated with the Puppet DSL might be nice?

    2. Assuming you have roles and profiles in modules, at what point do
    you specify the parameters to your modules? I am particularly
    interested in the answer to this question with regards to hiera. I
    find that I want to add roles and profiles to the hiera hierarchy, and
    I cannot come up with a way to do it.

    I think if hiera supported lookup by the class containing the hiera
    call, I could achieve what I want. For instance:

    class profiles::oneofmyprofiles {
    include myparameterizedclass
    }

    I would like to have a hiera.yaml like so:

    ---
    :backends:
    - yaml
    :hierarchy:
    - nodes/%{::hostname}
    - profiles/%{class_name}
    - common
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data


    Am I just completely off-base?

    --
    Chad M. Huneycutt

    --
    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.
    --
    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.
  • Chad Huneycutt at Feb 14, 2013 at 6:21 pm
    Unfortunately not. I am already using %{module_name}, and it works
    fine. But for what I am suggesting to work, I need to know the exact
    class where the hiera call is.

    - Chad
    On Wed, Feb 13, 2013 at 7:49 PM, Brian Lalor wrote:
    Will this help?
    http://docs.puppetlabs.com/puppet/3/reference/lang_variables.html#parser-set-variables

    --
    Brian Lalor
    blalor@bravo5.org

    On Feb 13, 2013, at 6:17 PM, Chad Huneycutt wrote:

    I have been following the various blog posts about the roles and
    profiles pattern for classifying hosts, and I like it. It doesn't
    provide a perfect fit for our infrastructure, but it is much better
    than the ad-hoc classification we do now. I have a couple of
    questions for those that use it, though:

    1. Where are you putting your role classes and profile classes? A
    role module and a profile module makes sense to me, but it seems like
    something more tightly integrated with the Puppet DSL might be nice?

    2. Assuming you have roles and profiles in modules, at what point do
    you specify the parameters to your modules? I am particularly
    interested in the answer to this question with regards to hiera. I
    find that I want to add roles and profiles to the hiera hierarchy, and
    I cannot come up with a way to do it.

    I think if hiera supported lookup by the class containing the hiera
    call, I could achieve what I want. For instance:

    class profiles::oneofmyprofiles {
    include myparameterizedclass
    }

    I would like to have a hiera.yaml like so:

    ---
    :backends:
    - yaml
    :hierarchy:
    - nodes/%{::hostname}
    - profiles/%{class_name}
    - common
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data


    Am I just completely off-base?

    --
    Chad M. Huneycutt

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


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


    --
    Chad M. Huneycutt

    --
    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.
  • Vaidas Jablonskis at Feb 14, 2013 at 11:54 am
    Hi there,

    I was going to ask exact same questions too.

    I am also interested in how people solve these problems.
    On Wednesday, 13 February 2013 23:17:40 UTC, Chad Huneycutt wrote:

    I have been following the various blog posts about the roles and
    profiles pattern for classifying hosts, and I like it. It doesn't
    provide a perfect fit for our infrastructure, but it is much better
    than the ad-hoc classification we do now. I have a couple of
    questions for those that use it, though:

    1. Where are you putting your role classes and profile classes? A
    role module and a profile module makes sense to me, but it seems like
    something more tightly integrated with the Puppet DSL might be nice?

    2. Assuming you have roles and profiles in modules, at what point do
    you specify the parameters to your modules? I am particularly
    interested in the answer to this question with regards to hiera. I
    find that I want to add roles and profiles to the hiera hierarchy, and
    I cannot come up with a way to do it.

    I think if hiera supported lookup by the class containing the hiera
    call, I could achieve what I want. For instance:

    class profiles::oneofmyprofiles {
    include myparameterizedclass
    }

    I would like to have a hiera.yaml like so:

    ---
    :backends:
    - yaml
    :hierarchy:
    - nodes/%{::hostname}
    - profiles/%{class_name}
    - common
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data


    Am I just completely off-base?

    --
    Chad M. Huneycutt
    --
    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 14, 2013 at 2:47 pm

    On Wednesday, February 13, 2013 5:17:40 PM UTC-6, Chad Huneycutt wrote:
    I would like to have a hiera.yaml like so:

    ---
    :backends:
    - yaml
    :hierarchy:
    - nodes/%{::hostname}
    - profiles/%{class_name}
    - common
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data


    Am I just completely off-base?
    No, but it's spelled %{calling_class}. There is also %{calling_module}.
    Do be aware of http://projects.puppetlabs.com/issues/14985, however.


    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.
  • Chad Huneycutt at Feb 14, 2013 at 6:08 pm
    It is my understanding that the calling_* variables are only available
    to the puppet backend. At least they do not work for me.
    %{module_name}, on the other hand, works as I expect it to with the
    yaml backend.
    On Thu, Feb 14, 2013 at 9:47 AM, jcbollinger wrote:

    On Wednesday, February 13, 2013 5:17:40 PM UTC-6, Chad Huneycutt wrote:

    I would like to have a hiera.yaml like so:

    ---
    :backends:
    - yaml
    :hierarchy:
    - nodes/%{::hostname}
    - profiles/%{class_name}
    - common
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data


    Am I just completely off-base?
    No, but it's spelled %{calling_class}. There is also %{calling_module}. Do
    be aware of http://projects.puppetlabs.com/issues/14985, however.


    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.


    --
    Chad M. Huneycutt

    --
    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 14, 2013 at 7:19 pm

    On Thursday, February 14, 2013 12:08:17 PM UTC-6, Chad Huneycutt wrote:
    It is my understanding that the calling_* variables are only available
    to the puppet backend. At least they do not work for me.
    %{module_name}, on the other hand, works as I expect it to with the
    yaml backend.
    I can't speak to whether or why these currently work for you, but they are
    certainly not targeted specifically at the Puppet back end. They are
    mostly intended for use in your hiera configuration file (hiera.yaml),
    which is independent of any particular back end (since it's where you
    define which one(s) to use). It's precisely the use case you described.

    With that said, it looks like at least one other bug has been filed against
    this functionality in Puppet 3, so perhaps you're running up against that.
    In any case, I still say no, you're not off-base: what you're asking for is
    supposed to already work.


    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.
  • Chad Huneycutt at Feb 14, 2013 at 7:45 pm
    Thanks, John. I think you are right that puppet should support it,
    but I am pretty sure it does not. I chatted with RI, and it seems
    that the classname is not "exposed", so when the puppet backend does
    the lookup, it figures out the classname and sets the 'calling_class'
    variable before it interprets the hierarchy. I am going to try to
    hack the same thing into the yaml backend, as well as file a bug (or
    +1 one) about it.

    - Chad
    On Thu, Feb 14, 2013 at 2:19 PM, jcbollinger wrote:

    On Thursday, February 14, 2013 12:08:17 PM UTC-6, Chad Huneycutt wrote:

    It is my understanding that the calling_* variables are only available
    to the puppet backend. At least they do not work for me.
    %{module_name}, on the other hand, works as I expect it to with the
    yaml backend.
    I can't speak to whether or why these currently work for you, but they are
    certainly not targeted specifically at the Puppet back end. They are mostly
    intended for use in your hiera configuration file (hiera.yaml), which is
    independent of any particular back end (since it's where you define which
    one(s) to use). It's precisely the use case you described.

    With that said, it looks like at least one other bug has been filed against
    this functionality in Puppet 3, so perhaps you're running up against that.
    In any case, I still say no, you're not off-base: what you're asking for is
    supposed to already work.


    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.


    --
    Chad M. Huneycutt

    --
    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 15, 2013 at 2:37 pm

    On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:
    Thanks, John. I think you are right that puppet should support it,
    but I am pretty sure it does not. I chatted with RI, and it seems
    that the classname is not "exposed", so when the puppet backend does
    the lookup, it figures out the classname and sets the 'calling_class'
    variable before it interprets the hierarchy. I am going to try to
    hack the same thing into the yaml backend, as well as file a bug (or
    +1 one) about it.
    Yes, R.I. was explaining the current state of the code, as is also
    summarized in the PL bug tracker. In addition to issue 14985, which we
    discussed above, there is http://projects.puppetlabs.com/issues/16730,
    which speaks directly to how %{calling_class} and %{calling_module} could
    be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed
    on that. That issue has been marked as a duplicate of 14985, however; I
    mention it to give you confidence about which issue to watch / vote up
    (14985). Also to confirm that PL not only agrees that there's an issue,
    but has a solution in flight.


    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.
  • Steve Roberts at Feb 16, 2013 at 5:01 am

    On Friday, February 15, 2013 6:37:10 AM UTC-8, jcbollinger wrote:

    On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:

    Thanks, John. I think you are right that puppet should support it,
    but I am pretty sure it does not. I chatted with RI, and it seems
    that the classname is not "exposed", so when the puppet backend does
    the lookup, it figures out the classname and sets the 'calling_class'
    variable before it interprets the hierarchy. I am going to try to
    hack the same thing into the yaml backend, as well as file a bug (or
    +1 one) about it.
    Yes, R.I. was explaining the current state of the code, as is also
    summarized in the PL bug tracker. In addition to issue 14985, which we
    discussed above, there is http://projects.puppetlabs.com/issues/16730,
    which speaks directly to how %{calling_class} and %{calling_module} could
    be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed
    on that. That issue has been marked as a duplicate of 14985, however; I
    mention it to give you confidence about which issue to watch / vote up
    (14985). Also to confirm that PL not only agrees that there's an issue,
    but has a solution in flight.

    This is very good to hear. A few of weeks ago I was told about the
    calling_* vars in #puppet IRC when I was looking to solve basically the
    same sort of task.

    then when I tried to use them this past weekend and it didn't work, I
    asked in #puppet again if there was an issue, and folks acted like I was
    crazy for thinking calling_{class,module} were supposed to work.

    Looking forward to having the issue resolved.


    --
    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.
  • JuanBrein at Mar 24, 2014 at 9:56 pm
    Today looking for a solution to this I came up with a nice solution. I know
    this thread is old but I'm posting it just in case is useful for somebody:

    on hiera.yaml:

    :hierarchy:
       - 'host/%{::domain}/%{::hostname}'
       - 'domain/%{::domain}'
       - 'role/%{system_role}'
       - 'common'

    on site.pp

    node default {

       $system_role = get_system_role()

    }

    and get_system_role is a custom function:

    require 'yaml'

    module Puppet::Parser::Functions

       newfunction(:get_system_role, :type => :rvalue) do |args|

         hostname = lookupvar('fqdn')

         enc = %x[/etc/puppet/node.rb #{hostname}]

         yaml = YAML::load enc

         system_role = yaml['classes'].keys.first.scan(/::([a-z]*)/).flatten[0]


       end

    end

    This is asuming you use an ENC to assign classes like foreman / cobbler or
    pe

    Cheers

    Juan
    On Saturday, February 16, 2013 5:00:59 AM UTC, Steve Roberts wrote:

    On Friday, February 15, 2013 6:37:10 AM UTC-8, jcbollinger wrote:


    On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:

    Thanks, John. I think you are right that puppet should support it,
    but I am pretty sure it does not. I chatted with RI, and it seems
    that the classname is not "exposed", so when the puppet backend does
    the lookup, it figures out the classname and sets the 'calling_class'
    variable before it interprets the hierarchy. I am going to try to
    hack the same thing into the yaml backend, as well as file a bug (or
    +1 one) about it.
    Yes, R.I. was explaining the current state of the code, as is also
    summarized in the PL bug tracker. In addition to issue 14985, which we
    discussed above, there is http://projects.puppetlabs.com/issues/16730,
    which speaks directly to how %{calling_class} and %{calling_module} could
    be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed
    on that. That issue has been marked as a duplicate of 14985, however; I
    mention it to give you confidence about which issue to watch / vote up
    (14985). Also to confirm that PL not only agrees that there's an issue,
    but has a solution in flight.

    This is very good to hear. A few of weeks ago I was told about the
    calling_* vars in #puppet IRC when I was looking to solve basically the
    same sort of task.

    then when I tried to use them this past weekend and it didn't work, I
    asked in #puppet again if there was an issue, and folks acted like I was
    crazy for thinking calling_{class,module} were supposed to work.

    Looking forward to having the issue resolved.
    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/be999593-f554-4e30-aab0-d75392a593a0%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Atom Powers at Mar 25, 2014 at 12:00 am
    This seems overly complicated. If you use an ENC then you can put arbitrary
    facts into the data returned by the ENC as "parameters". Since the ENC is
    processed before Hiera you can set your hierarchy based on those parameters
    and you can put anything else you want in there too.

    My ENC is similar to your ruby script, except that it basically just
    returns the data in
    heiradata/hosts/%{hostname}.yaml where I have something like:

    ---
    environment: 'production'
    parameters:
       role: 'web-server'
       department: 'marketing'
       manager: 'that-guy'


    And in your hiera.yaml

    ---
    :hierarchy:
      - roles/%{role}
      - departments/%{department}
      - managers/%{manager}


    On Mon, Mar 24, 2014 at 2:56 PM, JuanBrein wrote:

    Today looking for a solution to this I came up with a nice solution. I
    know this thread is old but I'm posting it just in case is useful for
    somebody:

    on hiera.yaml:

    :hierarchy:
    - 'host/%{::domain}/%{::hostname}'
    - 'domain/%{::domain}'
    - 'role/%{system_role}'
    - 'common'

    on site.pp

    node default {

    $system_role = get_system_role()

    }

    and get_system_role is a custom function:

    require 'yaml'

    module Puppet::Parser::Functions

    newfunction(:get_system_role, :type => :rvalue) do |args|

    hostname = lookupvar('fqdn')

    enc = %x[/etc/puppet/node.rb #{hostname}]

    yaml = YAML::load enc

    system_role = yaml['classes'].keys.first.scan(/::([a-z]*)/).flatten[0]


    end

    end

    This is asuming you use an ENC to assign classes like foreman / cobbler or
    pe

    Cheers

    Juan
    On Saturday, February 16, 2013 5:00:59 AM UTC, Steve Roberts wrote:

    On Friday, February 15, 2013 6:37:10 AM UTC-8, jcbollinger wrote:


    On Thursday, February 14, 2013 1:45:36 PM UTC-6, Chad Huneycutt wrote:

    Thanks, John. I think you are right that puppet should support it,
    but I am pretty sure it does not. I chatted with RI, and it seems
    that the classname is not "exposed", so when the puppet backend does
    the lookup, it figures out the classname and sets the 'calling_class'
    variable before it interprets the hierarchy. I am going to try to
    hack the same thing into the yaml backend, as well as file a bug (or
    +1 one) about it.
    Yes, R.I. was explaining the current state of the code, as is also
    summarized in the PL bug tracker. In addition to issue 14985, which we
    discussed above, there is http://projects.puppetlabs.com/issues/16730,
    which speaks directly to how %{calling_class} and %{calling_module} could
    be used in hiera.yaml in Puppet 2.7, whereas Puppet 3 apparently regressed
    on that. That issue has been marked as a duplicate of 14985, however; I
    mention it to give you confidence about which issue to watch / vote up
    (14985). Also to confirm that PL not only agrees that there's an issue,
    but has a solution in flight.

    This is very good to hear. A few of weeks ago I was told about the
    calling_* vars in #puppet IRC when I was looking to solve basically the
    same sort of task.

    then when I tried to use them this past weekend and it didn't work, I
    asked in #puppet again if there was an issue, and folks acted like I was
    crazy for thinking calling_{class,module} were supposed to work.

    Looking forward to having the issue resolved.
    --
    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 view this discussion on the web visit
    https://groups.google.com/d/msgid/puppet-users/be999593-f554-4e30-aab0-d75392a593a0%40googlegroups.com<https://groups.google.com/d/msgid/puppet-users/be999593-f554-4e30-aab0-d75392a593a0%40googlegroups.com?utm_medium=email&utm_source=footer>
    .
    For more options, visit https://groups.google.com/d/optout.


    --
    Perfection is just a word I use occasionally with mustard.
    --Atom Powers--

    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF-H%3DOmReuQxX51Ux0xAjQDEnLNdBy%2B-mMEeLkFPHP%2BrOXRVPg%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedFeb 13, '13 at 11:17p
activeMar 25, '14 at 12:00a
posts12
users7
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase