FAQ
After reading several posts, it looks like setting a key on every host, and
supplying a different value based on that host's function is not a proper
use of facts, but more for variables.

We are using hiera, and based on my hierarchy,


:hierarchy:
- common
- %{application}
:yaml:
:datadir: /etc/puppetlabs/hieradata/%{environment}

Without using an ENC, what's are some good ways to "tag" the server with a
value for %{application}.

thanks so much,

Tony


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

  • Dan White at Apr 8, 2013 at 6:34 pm
    I am still confuzzled by your "application"

    Would you provide a more specific example ?
    I am thinking that this is something that can be controlled at the module level

    http://docs.puppetlabs.com/puppet/latest/reference/lang_variables.html#parser-set-variables


    “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ----- Original Message -----
    From: "Tony C" <tonyjchong@gmail.com>
    To: puppet-users@googlegroups.com
    Sent: Monday, April 8, 2013 2:28:40 PM
    Subject: [Puppet Users] Not custom facts, but variables?

    After reading several posts, it looks like setting a key on every host, and supplying a different value based on that host's function is not a proper use of facts, but more for variables.


    We are using hiera, and based on my hierarchy,






    :hierarchy:
    - common
    - %{application}

    :yaml:
    :datadir: /etc/puppetlabs/hieradata/%{environment}


    Without using an ENC, what's are some good ways to "tag" the server with a value for %{application}.


    thanks so much,


    Tony





    --
    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.
  • Tony C at Apr 8, 2013 at 6:43 pm
    sure, to be specific,

    we have environments, dev, test, qa, stage, and prod. That part I got with
    your help on my last post. Thank you.

    Within these environments, we have applications. We only have a few apps.
    So let's say some machines are oracle db machines, some are tomcat, and
    some are apache.

    I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
    of these yaml files contain some key value pair that is specific to that
    environment.

    So when some machine is provisioned, I want to say this machine is a tomcat
    machine, and I don't care what environment it since I will let the agent
    conf figure that out. That way I can one puppet module for tomcat, but
    different values per environment.

    I hope that makes sense, and if my approach is completely wrong, I'm open
    to hear some alternatives. Thanks again everyone.

    --
    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.
  • Dan White at Apr 8, 2013 at 6:57 pm
    Based on your description, I would suggest the following:

    Let's take tomcat as a specific example.
    Assumption: You have a tomcat module that can be configured with parameters.

    Here is the suggestion: Add a hostname level to your heirarchy.

    OK, so now for node hostx.example.org, you want this to be a tomcat server. All you need do is put the appropriate parameters into hostx.example.org.yaml

    I am still a hiera n00b myself, so I am not totally sure exactly how to do this, but I am working on it.


    “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ----- Original Message -----
    From: "Tony C" <tonyjchong@gmail.com>
    To: puppet-users@googlegroups.com
    Sent: Monday, April 8, 2013 2:43:41 PM
    Subject: Re: [Puppet Users] Not custom facts, but variables?

    sure, to be specific,


    we have environments, dev, test, qa, stage, and prod. That part I got with your help on my last post. Thank you.


    Within these environments, we have applications. We only have a few apps. So let's say some machines are oracle db machines, some are tomcat, and some are apache.


    I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of these yaml files contain some key value pair that is specific to that environment.


    So when some machine is provisioned, I want to say this machine is a tomcat machine, and I don't care what environment it since I will let the agent conf figure that out. That way I can one puppet module for tomcat, but different values per environment.


    I hope that makes sense, and if my approach is completely wrong, I'm open to hear some alternatives. Thanks again everyone.

    --
    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.
  • Jonathan Proulx at Apr 8, 2013 at 7:14 pm

    On Mon, Apr 8, 2013 at 2:57 PM, Dan White wrote:

    Based on your description, I would suggest the following:

    Let's take tomcat as a specific example.
    Assumption: You have a tomcat module that can be configured with
    parameters.

    Here is the suggestion: Add a hostname level to your heirarchy

    but if you have multiple tomcat servers (for example) then you have to
    repeat data for each hostname which is exactly the wrong thing.

    using a custom fact (I use "role" for essentially the same thing Tony wants
    to use "application for) you can classify nodes without an ENC and without
    repeating yourself.

    My hierarchy is:
    # cat /etc/puppet/hiera.yaml
    ---
    :hierarchy:
    - %{fqdn}
    - %{role}
    - %{group}
    - %{osfamily}
    - common
    :backends:
    - yaml
    - puppet
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data
    :puppet:
    :datasource: data

    I do have fqdn, but that is always too specific, except maybe for testing.
    "Role" is what the system does and "group" is who manages it, both of these
    come form custom facts on the system in /etc/factor/facts.d (requires
    puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds)
    with the same role. Keying this off fqdn or cert name would me a nightmare

    Picking the right hierarchy and the right level into to place data is a bit
    of a black art, but crucial to having a manageable config. This has been
    workable for me for the past 9 months or so, but not pretenses to
    perfection...

    -Jon


    OK, so now for node hostx.example.org, you want this to be a tomcat
    server. All you need do is put the appropriate parameters into
    hostx.example.org.yaml

    I am still a hiera n00b myself, so I am not totally sure exactly how to do
    this, but I am working on it.


    “Sometimes I think the surest sign that intelligent life exists elsewhere
    in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ------------------------------
    *From: *"Tony C" <tonyjchong@gmail.com>
    *To: *puppet-users@googlegroups.com
    *Sent: *Monday, April 8, 2013 2:43:41 PM
    *Subject: *Re: [Puppet Users] Not custom facts, but variables?


    sure, to be specific,

    we have environments, dev, test, qa, stage, and prod. That part I got with
    your help on my last post. Thank you.

    Within these environments, we have applications. We only have a few apps.
    So let's say some machines are oracle db machines, some are tomcat, and
    some are apache.

    I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
    of these yaml files contain some key value pair that is specific to that
    environment.

    So when some machine is provisioned, I want to say this machine is a
    tomcat machine, and I don't care what environment it since I will let the
    agent conf figure that out. That way I can one puppet module for tomcat,
    but different values per environment.

    I hope that makes sense, and if my approach is completely wrong, I'm open
    to hear some alternatives. Thanks again everyone.

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

    --
    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.
  • Dan White at Apr 8, 2013 at 7:25 pm
    That looks great.

    Another thing to consider: As of hiera 1.2.0, you have deep merge for hashes.
    You do not need to repeat parameters at every level !


    “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ----- Original Message -----
    From: "Jonathan Proulx" <jon@jonproulx.com>
    To: puppet-users@googlegroups.com
    Sent: Monday, April 8, 2013 3:14:04 PM
    Subject: Re: [Puppet Users] Not custom facts, but variables?


    On Mon, Apr 8, 2013 at 2:57 PM, Dan White wrote:






    Based on your description, I would suggest the following:

    Let's take tomcat as a specific example.
    Assumption: You have a tomcat module that can be configured with parameters.

    Here is the suggestion: Add a hostname level to your heirarchy






    but if you have multiple tomcat servers (for example) then you have to repeat data for each hostname which is exactly the wrong thing.


    using a custom fact (I use "role" for essentially the same thing Tony wants to use "application for) you can classify nodes without an ENC and without repeating yourself.


    My hierarchy is:
    # cat /etc/puppet/hiera.yaml
    ---
    :hierarchy:
    - %{fqdn}
    - %{role}
    - %{group}
    - %{osfamily}
    - common
    :backends:
    - yaml
    - puppet
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data
    :puppet:
    :datasource: data


    I do have fqdn, but that is always too specific, except maybe for testing. "Role" is what the system does and "group" is who manages it, both of these come form custom facts on the system in /etc/factor/facts.d (requires puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds) with the same role. Keying this off fqdn or cert name would me a nightmare


    Picking the right hierarchy and the right level into to place data is a bit of a black art, but crucial to having a manageable config. This has been workable for me for the past 9 months or so, but not pretenses to perfection...



    -Jon





    <blockquote>


    OK, so now for node hostx.example.org , you want this to be a tomcat server. All you need do is put the appropriate parameters into hostx.example.org.yaml

    I am still a hiera n00b myself, so I am not totally sure exactly how to do this, but I am working on it.



    “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)


    From: "Tony C" < tonyjchong@gmail.com >
    To: puppet-users@googlegroups.com
    Sent: Monday, April 8, 2013 2:43:41 PM
    Subject: Re: [Puppet Users] Not custom facts, but variables?



    sure, to be specific,


    we have environments, dev, test, qa, stage, and prod. That part I got with your help on my last post. Thank you.


    Within these environments, we have applications. We only have a few apps. So let's say some machines are oracle db machines, some are tomcat, and some are apache.


    I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of these yaml files contain some key value pair that is specific to that environment.


    So when some machine is provisioned, I want to say this machine is a tomcat machine, and I don't care what environment it since I will let the agent conf figure that out. That way I can one puppet module for tomcat, but different values per environment.


    I hope that makes sense, and if my approach is completely wrong, I'm open to hear some alternatives. Thanks again everyone.

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



    </blockquote>



    --
    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.
  • Jonathan Proulx at Apr 8, 2013 at 7:41 pm

    On Mon, Apr 8, 2013 at 3:25 PM, Dan White wrote:

    That looks great.

    Another thing to consider: As of hiera 1.2.0, you have deep merge for
    hashes.
    You do not need to repeat parameters at every level !

    That's good to know. We've been using hiera arrays to collect things like
    classes and packages from multiple levels of the hierarchy, this lets me
    keep a site.pp that is essentially:

    node default {
    hiera_include("classes")
    }

    and pull in all packages that are required (but not otherwise managed) with:

    $basepackages = hiera_array('basepackages')
    package { $basepackages:
    ensure => latest,
    require => Class['csail::apt::csailrepo'],
    }

    we use this for things like development tool and desktop applications that
    we want installed but aren't otherwise manages (unlike services that
    generally have their own module to handle all that). In both cases clsees
    and packages can be defined at any level of the hierarchy and all that are
    found are activated.

    being able to merge hashes like that sounds interesting, though perhaps the
    topic is starting to drift a bit....

    --
    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.
  • Tony C at Apr 8, 2013 at 7:33 pm
    Jon,

    Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar
    with this module. I read on it but not sure specifically how you are using
    it.

    Thanks,

    Tony
    On Monday, April 8, 2013 12:14:04 PM UTC-7, Jonathan Proulx wrote:

    On Mon, Apr 8, 2013 at 2:57 PM, Dan White <yg...@comcast.net <javascript:>
    wrote:
    Based on your description, I would suggest the following:

    Let's take tomcat as a specific example.
    Assumption: You have a tomcat module that can be configured with
    parameters.

    Here is the suggestion: Add a hostname level to your heirarchy

    but if you have multiple tomcat servers (for example) then you have to
    repeat data for each hostname which is exactly the wrong thing.

    using a custom fact (I use "role" for essentially the same thing Tony
    wants to use "application for) you can classify nodes without an ENC and
    without repeating yourself.

    My hierarchy is:
    # cat /etc/puppet/hiera.yaml
    ---
    :hierarchy:
    - %{fqdn}
    - %{role}
    - %{group}
    - %{osfamily}
    - common
    :backends:
    - yaml
    - puppet
    :yaml:
    :datadir: /etc/puppet/environments/%{environment}/data
    :puppet:
    :datasource: data

    I do have fqdn, but that is always too specific, except maybe for
    testing. "Role" is what the system does and "group" is who manages it,
    both of these come form custom facts on the system in /etc/factor/facts.d
    (requires puppetlabs_stdlib) so I can have multiple nodes (in some cases
    hundreds) with the same role. Keying this off fqdn or cert name would me a
    nightmare

    Picking the right hierarchy and the right level into to place data is a
    bit of a black art, but crucial to having a manageable config. This has
    been workable for me for the past 9 months or so, but not pretenses to
    perfection...

    -Jon


    OK, so now for node hostx.example.org, you want this to be a tomcat
    server. All you need do is put the appropriate parameters into
    hostx.example.org.yaml

    I am still a hiera n00b myself, so I am not totally sure exactly how to
    do this, but I am working on it.


    “Sometimes I think the surest sign that intelligent life exists elsewhere
    in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ------------------------------
    *From: *"Tony C" <tonyj...@gmail.com <javascript:>>
    *To: *puppet...@googlegroups.com <javascript:>
    *Sent: *Monday, April 8, 2013 2:43:41 PM
    *Subject: *Re: [Puppet Users] Not custom facts, but variables?


    sure, to be specific,

    we have environments, dev, test, qa, stage, and prod. That part I got
    with your help on my last post. Thank you.

    Within these environments, we have applications. We only have a few apps.
    So let's say some machines are oracle db machines, some are tomcat, and
    some are apache.

    I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
    of these yaml files contain some key value pair that is specific to that
    environment.

    So when some machine is provisioned, I want to say this machine is a
    tomcat machine, and I don't care what environment it since I will let the
    agent conf figure that out. That way I can one puppet module for tomcat,
    but different values per environment.

    I hope that makes sense, and if my approach is completely wrong, I'm open
    to hear some alternatives. Thanks again everyone.

    --
    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...@googlegroups.com <javascript:>.
    To post to this group, send email to puppet...@googlegroups.com<javascript:>
    .
    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...@googlegroups.com <javascript:>.
    To post to this group, send email to puppet...@googlegroups.com<javascript:>
    .
    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.
  • Jonathan Proulx at Apr 8, 2013 at 8:02 pm

    On Mon, Apr 8, 2013 at 3:33 PM, Tony C wrote:

    Jon,

    Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar
    with this module. I read on it but not sure specifically how you are using
    it.
    stdlib provides many useful functions, most of which are called by other
    modules.

    The use that relates to this case is "facter-dot-d" see
    https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for
    a write up.

    The simple case (which is the one we use is making a plain text file in
    /etc/facter/facts.d (anything in there ending in .txt gets parsed as plain
    text)) with key=value pairs that then become facter facts.

    for example on my puppet managed workstation:

    $ cat /etc/facter/facts.d/csail.txt
    role=wkst
    autofs=true

    So when puppet runs the fact "role" is set to "wkst" which pulls in the
    right classes to make a generic workstation, the fact "group" mentioned
    above is undefined which is OK there's just no customization based on
    groups and "autofs" is a facter key that our local wkst module looks at to
    see if our NFS automount should be configured or not. By default we don't
    but the local root user can define this to true and on the next puppet run
    the config will happen for them.

    We install the stdlib module on the puppet masters (implemneted as a git
    submodule in our git repo) and use "pluginsync=true" on the clients to pull
    down the bits they need from this and other modules. Though you could
    distribute the required facter-dot-d.rb file in other ways, pluginsync is
    most convenient for us.

    -Jon

    --
    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.
  • Tony C at Apr 8, 2013 at 8:18 pm
    Right on!

    Thanks Jon,

    That was it. Got it working just as you stated. It's exactly what I need.

    Tony
    On Monday, April 8, 2013 1:01:58 PM UTC-7, Jonathan Proulx wrote:


    On Mon, Apr 8, 2013 at 3:33 PM, Tony C <tonyj...@gmail.com <javascript:>>wrote:
    Jon,

    Can you tell me some more detail about puppetlabs_stdlib? I am unfamiliar
    with this module. I read on it but not sure specifically how you are using
    it.
    stdlib provides many useful functions, most of which are called by other
    modules.

    The use that relates to this case is "facter-dot-d" see
    https://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3/for a write up.

    The simple case (which is the one we use is making a plain text file in
    /etc/facter/facts.d (anything in there ending in .txt gets parsed as plain
    text)) with key=value pairs that then become facter facts.

    for example on my puppet managed workstation:

    $ cat /etc/facter/facts.d/csail.txt
    role=wkst
    autofs=true

    So when puppet runs the fact "role" is set to "wkst" which pulls in the
    right classes to make a generic workstation, the fact "group" mentioned
    above is undefined which is OK there's just no customization based on
    groups and "autofs" is a facter key that our local wkst module looks at to
    see if our NFS automount should be configured or not. By default we don't
    but the local root user can define this to true and on the next puppet run
    the config will happen for them.

    We install the stdlib module on the puppet masters (implemneted as a git
    submodule in our git repo) and use "pluginsync=true" on the clients to pull
    down the bits they need from this and other modules. Though you could
    distribute the required facter-dot-d.rb file in other ways, pluginsync is
    most convenient for us.

    -Jon
    --
    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.
  • Tony C at Apr 8, 2013 at 7:32 pm
    Thanks for your response, but I can see me possibly having tons of yaml
    files since it's very possible I may have 100 tomcat servers, all with the
    same configuration. I don't think it will scale.

    On Monday, April 8, 2013 11:57:10 AM UTC-7, Ygor wrote:

    Based on your description, I would suggest the following:

    Let's take tomcat as a specific example.
    Assumption: You have a tomcat module that can be configured with
    parameters.

    Here is the suggestion: Add a hostname level to your heirarchy.

    OK, so now for node hostx.example.org, you want this to be a tomcat
    server. All you need do is put the appropriate parameters into
    hostx.example.org.yaml

    I am still a hiera n00b myself, so I am not totally sure exactly how to do
    this, but I am working on it.

    “Sometimes I think the surest sign that intelligent life exists elsewhere
    in the universe is that none of it has tried to contact us.”
    Bill Waterson (Calvin & Hobbes)

    ------------------------------
    *From: *"Tony C" <tonyj...@gmail.com <javascript:>>
    *To: *puppet...@googlegroups.com <javascript:>
    *Sent: *Monday, April 8, 2013 2:43:41 PM
    *Subject: *Re: [Puppet Users] Not custom facts, but variables?

    sure, to be specific,

    we have environments, dev, test, qa, stage, and prod. That part I got with
    your help on my last post. Thank you.

    Within these environments, we have applications. We only have a few apps.
    So let's say some machines are oracle db machines, some are tomcat, and
    some are apache.

    I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each
    of these yaml files contain some key value pair that is specific to that
    environment.

    So when some machine is provisioned, I want to say this machine is a
    tomcat machine, and I don't care what environment it since I will let the
    agent conf figure that out. That way I can one puppet module for tomcat,
    but different values per environment.

    I hope that makes sense, and if my approach is completely wrong, I'm open
    to hear some alternatives. Thanks again everyone.

    --
    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...@googlegroups.com <javascript:>.
    To post to this group, send email to puppet...@googlegroups.com<javascript:>
    .
    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.
  • Jonathan Proulx at Apr 8, 2013 at 6:39 pm

    On Mon, Apr 8, 2013 at 2:28 PM, Tony C wrote:

    After reading several posts, it looks like setting a key on every host,
    and supplying a different value based on that host's function is not a
    proper use of facts, but more for variables.

    We are using hiera, and based on my hierarchy,


    :hierarchy:
    - common
    - %{application}
    :yaml:
    :datadir: /etc/puppetlabs/hieradata/%{environment}

    Without using an ENC, what's are some good ways to "tag" the server with a
    value for %{application}.
    I do exactly this using facts.

    using puppetlabs_stdlib module to provide simple custom facts from
    /etc/facter/facts.d (after partitioning and installing a base OS) our
    install process writes a custom text file to this directory defining facts
    for "role", "group" and "cluster" which are all parts of our hiera
    hierarchy and then calls puppet for the first time.

    This may not be the best way in a more orderly environment but I work in an
    academic research lab so have lots of messy edge cases that can't be
    determined by name or IP and need to delegate these definitions to people
    who are not admin enough to have access to our puppet repo but do have
    local root on the systems they manage...

    -Jon

    --
    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.
  • Tony C at Apr 8, 2013 at 8:01 pm
    Looks like external facts are available after facter 1.7, i'm using 1.6

    --
    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
postedApr 8, '13 at 6:28p
activeApr 8, '13 at 8:18p
posts13
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase