FAQ
Hi All,

In our environment, we use the $::environment variable extensively to
determine if the host should have one set of mounts (e.g. production) or a
different set of mounts (e.g. qa). This is just one example, but there are
many others where the $::environment variable comes into play.

The problem is that I have a number of puppet changes that I want to test
before merging into the production tree, so I've created a staging
environment.... however, given the importance of the $::environment
variable throughout the manifests, this won't work well.

Any suggestions? I'd like to point a number of production nodes at a
secondary puppet server using --noop to see what would change, but then I
run into SSL issues. Would be great if I could use puppet over cleartext
http for this test, but I'm not sure if that's possible.

Thanks in advance for any feedback.
Gonzalo

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

Search Discussions

  • Luke Bigum at Sep 19, 2012 at 8:43 am

    On 19/09/12 06:11, Gonzalo Servat wrote:
    Hi All,

    In our environment, we use the $::environment variable extensively to
    determine if the host should have one set of mounts (e.g. production)
    or a different set of mounts (e.g. qa). This is just one example, but
    there are many others where the $::environment variable comes into play.

    The problem is that I have a number of puppet changes that I want to
    test before merging into the production tree, so I've created a
    staging environment.... however, given the importance of the
    $::environment variable throughout the manifests, this won't work
    I think the only way to get around this problem is to copy
    $::environment to $::my_environment or some such, and then change all
    the references to use $::my_environment. Then you could have a selective
    case in 'staging' where it forcefully sets $my_environment to either
    'prod' or 'qa' in your case.
    Any suggestions? I'd like to point a number of production nodes at a
    secondary puppet server using --noop to see what would change, but
    then I run into SSL issues. Would be great if I could use puppet over
    cleartext http for this test, but I'm not sure if that's possible.
    If you set up a second Puppet Master and synchronise the CA and all the
    signed certificates from your primary to your "slave" Master, it should
    work. I would forcefully turn certificate signing off on your "slave" in
    puppet.conf. Dan Bode wrote a great article ages ago about multi-master
    Puppet which you might want to reference: http://bodepd.com/wordpress/?p=7
    Thanks in advance for any feedback.
    Gonzalo
    --
    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.

    --
    Luke Bigum
    Senior Systems Engineer

    Information Systems
    Ph: +44 (0) 20 3192 2520
    luke.bigum@lmax.com | http://www.lmax.com
    LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN


    FX and CFDs are leveraged products that can result in losses exceeding
    your deposit. They are not suitable for everyone so please ensure you
    fully understand the risks involved. The information in this email is not
    directed at residents of the United States of America or any other
    jurisdiction where trading in CFDs and/or FX is restricted or prohibited
    by local laws or regulations.

    The information in this email and any attachment is confidential and is
    intended only for the named recipient(s). The email may not be disclosed
    or used by any person other than the addressee, nor may it be copied in
    any way. If you are not the intended recipient please notify the sender
    immediately and delete any copies of this message. Any unauthorised
    copying, disclosure or distribution of the material in this e-mail is
    strictly forbidden.

    LMAX operates a multilateral trading facility. Authorised and regulated
    by the Financial Services Authority (firm registration number 509778) and
    is registered in England and Wales (number 06505809).
    Our registered address is Yellow Building, 1A Nicholas Road, London, W11
    4AN.

    --
    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 Sep 19, 2012 at 1:41 pm

    On Wednesday, September 19, 2012 12:11:24 AM UTC-5, Gonzalo wrote:
    Hi All,

    In our environment, we use the $::environment variable extensively to
    determine if the host should have one set of mounts (e.g. production) or a
    different set of mounts (e.g. qa). This is just one example, but there are
    many others where the $::environment variable comes into play.

    The problem is that I have a number of puppet changes that I want to test
    before merging into the production tree, so I've created a staging
    environment.... however, given the importance of the $::environment
    variable throughout the manifests, this won't work well.

    Any suggestions? I'd like to point a number of production nodes at a
    secondary puppet server using --noop to see what would change, but then I
    run into SSL issues. Would be great if I could use puppet over cleartext
    http for this test, but I'm not sure if that's possible.

    I tend to think that the $::environment fact is not a very good choice for
    testing your Puppet configuration, for pretty much the reason you already
    described. Setting up a secondary master for testing is exactly what I
    would recommend.

    There are a number of ways that you could work out the SSL issues. The
    brute force way, for example, would involve synchronizing the masters' SSL
    directories (both directions), and probably playing some games with name
    servers. It would be more elegant to set up a central CA on which the
    masters and clients all rely, though synchronization of client certs
    between the masters would probably still be needed. In a pinch, you might
    be able to enlist your existing production master as the central CA.


    John

    --
    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/-/k0EStMzrmB0J.
    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.
  • Glenn Poston at Sep 19, 2012 at 10:04 pm
    Use heira. Heira can load a config file based on the environment. Setting this up is as simple as creating a hiera definition such as...

    (environment).yaml

    ... And then creating the following files: production.yaml and staging.yaml that contain your environment specific configs.

    Install the puppet-hiera gem, then you can lookup the appropriate command inside puppet using heira_lookup(param_name).

    For an example, checkout the vagrant-hiera project on github. If your unfamiliar with vagrant, you'll need to install that to run the example. It's a great tool for doing local puppet testing. Even if you don't want to install vagrant, looking at the source of that project will show you a quick example of how to use hiera.

    --
    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/-/YlJx3dHegBsJ.
    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.
  • Gonzalo Servat at Sep 19, 2012 at 11:53 pm
    Hi All,

    Thanks for your feedback. While writing the original email, the subject
    sounded familiar and that's because I had written about it in the past:

    https://groups.google.com/d/topic/puppet-users/twLhIwsCRu4/discussion

    Apologies to those involved in the other thread for not replying, but thank
    you for your feedback. I ended up doing what Pablo F suggested, which is to
    run a puppetmasterd instance as a user, that way I use a copy of the
    /var/lib/puppet directory and the certificates work fine.

    Glenn, I like the hiera idea (currently I'm using extlookup) but I think I
    would run into the same problem. In some of my erb templates, settings are
    set depending on the environment. For example, in my.cnf (for MySQL), we
    set the innodb buffer pool size to different sizes depending on the
    environment. How would I set specific settings depending on the environment
    here?

    Cheers
    Gonzalo
    On Thu, Sep 20, 2012 at 8:04 AM, Glenn Poston wrote:

    Use heira. Heira can load a config file based on the environment.
    Setting this up is as simple as creating a hiera definition such as...

    (environment).yaml

    ... And then creating the following files: production.yaml and
    staging.yaml that contain your environment specific configs.

    Install the puppet-hiera gem, then you can lookup the appropriate command
    inside puppet using heira_lookup(param_name).

    For an example, checkout the vagrant-hiera project on github. If your
    unfamiliar with vagrant, you'll need to install that to run the example.
    It's a great tool for doing local puppet testing. Even if you don't want
    to install vagrant, looking at the source of that project will show you a
    quick example of how to use hiera.

    --
    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/-/YlJx3dHegBsJ.
    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.
    --
    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.
  • Garrett Honeycutt at Sep 20, 2012 at 5:37 am

    On 9/19/12 4:53 PM, Gonzalo Servat wrote:
    Hi All,

    Thanks for your feedback. While writing the original email, the subject
    sounded familiar and that's because I had written about it in the past:

    https://groups.google.com/d/topic/puppet-users/twLhIwsCRu4/discussion

    Apologies to those involved in the other thread for not replying, but
    thank you for your feedback. I ended up doing what Pablo F suggested,
    which is to run a puppetmasterd instance as a user, that way I use a
    copy of the /var/lib/puppet directory and the certificates work fine.
    No need at all to use a different puppet master, you could just use
    environments[1]. When you want to test a system again a different
    environment, staging in this example, you can run `puppet agent -t
    --environment=staging`.
    Glenn, I like the hiera idea (currently I'm using extlookup) but I think
    I would run into the same problem. In some of my erb templates, settings
    are set depending on the environment. For example, in my.cnf (for
    MySQL), we set the innodb buffer pool size to different sizes depending
    on the environment. How would I set specific settings depending on the
    environment here?

    Cheers
    Gonzalo
    Hiera[2] is meant to solve this. You might have staging.yaml and
    production.yaml that specify values for mysql_innodb_buffer_pool_size.

    In your code you could have

    $innodb_buffer_pool_size = hiera('mysql_innodb_buffer_pool_size')

    and then use <%= innodb_buffer_pool_size %> in a template for your my.cnf.

    -g


    [1] - http://docs.puppetlabs.com/guides/environment.html
    [2] - https://github.com/puppetlabs/hiera-puppet/blob/master/README.md

    --
    Garrett Honeycutt

    206.414.8658
    http://puppetlabs.com

    --
    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.
  • Gonzalo Servat at Sep 20, 2012 at 5:43 am

    On Thu, Sep 20, 2012 at 3:37 PM, Garrett Honeycutt wrote:

    No need at all to use a different puppet master, you could just use
    environments[1]. When you want to test a system again a different
    environment, staging in this example, you can run `puppet agent -t
    --environment=staging`.
    Yep, I need to move towards this. I guess this means I need to go through
    all my templates and put hiera variables for everything.

    Hiera[2] is meant to solve this. You might have staging.yaml and
    production.yaml that specify values for mysql_innodb_buffer_pool_size.

    In your code you could have

    $innodb_buffer_pool_size = hiera('mysql_innodb_buffer_pool_size')

    and then use <%= innodb_buffer_pool_size %> in a template for your my.cnf.
    Can one call hiera() from within the ERB templates?

    - Gonzalo

    --
    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.
  • Garrett Honeycutt at Sep 20, 2012 at 2:43 pm

    On 9/19/12 10:43 PM, Gonzalo Servat wrote:
    On Thu, Sep 20, 2012 at 3:37 PM, Garrett Honeycutt
    wrote:

    No need at all to use a different puppet master, you could just use
    environments[1]. When you want to test a system again a different
    environment, staging in this example, you can run `puppet agent -t
    --environment=staging`.


    Yep, I need to move towards this. I guess this means I need to go
    through all my templates and put hiera variables for everything.


    Hiera[2] is meant to solve this. You might have staging.yaml and
    production.yaml that specify values for mysql_innodb_buffer_pool_size.

    In your code you could have

    $innodb_buffer_pool_size = hiera('mysql_innodb_buffer_pool_size')

    and then use <%= innodb_buffer_pool_size %> in a template for your
    my.cnf.


    Can one call hiera() from within the ERB templates?

    - Gonzalo
    No, you call it from the manifests. Recommend reading the hiera
    documentation. Also you can see an example with my dnsclient module[1].

    [1] -
    https://github.com/ghoneycutt/puppet-dnsclient/tree/new_design_pattern_with_hiera

    -g


    --
    Garrett Honeycutt

    206.414.8658
    http://puppetlabs.com

    --
    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 Sep 21, 2012 at 4:27 pm
    I seem to be missing something here. The OP's problem is that part of what
    he wants to test is his code's environment-dependent behavior. I maintain
    that no solution requiring a different environment to be declared than the
    one he wants to test can in fact test such behavior adequately. I don't
    see how hiera into the mix changes that in any way.

    The same considerations apply to a lesser extent to using some different
    data to distingish environment-A-testing from environment-A-production:
    when you want to transition the test code and data to production, it can
    really be quite tricky to make the latter act exactly as the former did,
    but when fed with different data.

    Environments are fine for a lot of things, including configuring test
    environments for other software, but they are not so good for testing
    Puppet itself. I maintain that the best approach is to stand up test
    manifests and data in a separate master, leveraging your SCM system to put
    that code and data into production when the time comes. That way you can
    be confident that you have tested the scenarios that will actually be
    encountered when your code goes live.


    John

    --
    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/-/2P1W_Br_FpYJ.
    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.
  • Gonzalo Servat at Sep 20, 2012 at 2:38 pm

    On Thu, Sep 20, 2012 at 3:37 PM, Garrett Honeycutt wrote:

    Hiera[2] is meant to solve this. You might have staging.yaml and
    production.yaml that specify values for mysql_innodb_buffer_pool_size.
    Another scenario I've found is that we also add certain users if
    $::environment is production, and a different set of users if it's qa, etc.
    How would you work with that using hiera?

    One idea that comes to mind is that within hiera I set a special
    environment variable called $::env or something, which is what I would
    evaluate instead of $::environment, that way I can have any puppet
    environment setting $::env to whatever I want.

    - Gonzalo

    --
    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
postedSep 19, '12 at 5:11a
activeSep 21, '12 at 4:27p
posts10
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase