Issue #11900 has been updated by Nigel Kersten.
Mike McLane wrote: > Thank you for looking into this Nigel. > > Yes, I believe those involved with this thread understand how dynamic > environments work currently. > > What I'm trying to do is set different module load paths based on the > environment. > > This might be satisfied if there was a way to set multiple dynamic > environments on a single master, That's why I'm a little confused :) as you can do this now. You just need to create the relevant directory hierarchy underneath `/foo/` in my example above. Each environment will have a different module load path. > modify module load paths at run-time, or do variable interpolation from > within the puppet master config file. Yep, I've hit cases in the past where I wished we could set the module load path at run time... Let me get a little more concrete: > > In our multi-team environment it is important that each team can ingest > enterprise-provided classes but also have the ability to over-ride those > classes with updates either at the team-wide path or at their team-product > specific path > So wouldn't this work? <pre> [master] modulepath = /var/lib/puppet/environments/$environment/modules:/var/lib/puppet/core-enterprise/modules: manifest = /var/lib/puppet/environments/$environment/manifests/site.pp </pre> I assume you're using version control, and you can set up a sync task between some VCS location and /var/lib/puppet/environments. The teams can dynamically define environments by checking code in that maps to `/var/lib/puppet/environments/foobarbaz` and their agents can use 'foobarbaz' as the environment. > We also would prefer not to having to restart the puppet masters every time a > new environment needs to be added. I took a different approach in the past with a very similar set of needs, and had a .yaml file in version control that described each environment and the module path. This meant developers could add environments with their own combination of directories for the modulepath. This synced regularly to the master, and we used an .erb template to evaluate the yaml file, and create `[environmentname]` blocks in puppet.conf. I did this because we needed to be able to not only define environments to segment teams, but for the classic `dev -> test -> prod` cycle for each team-specified environment as well. If you touch puppet.conf, the puppetmaster process automatically picks up the changes and you don't need to restart it. ---------------------------------------- Feature #11900: Dynamic environment interpolation in puppet master configuration https://projects.puppetlabs.com/issues/11900 Author: Mike McLane Status: Needs More Information Priority: Normal Assignee: Kelsey Hightower Category: server Target version: Affected Puppet version: development Keywords: dynamic environment, puppet master configuration, interopolated configuration, environment parameter Branch: In providing a single Puppet master to multiple teams, where each team has their own test/release cadence, we maintain that each team would like to include their own dynamic module path based on the environment passed from the agent. We have a re-usability case where an enterprise level of common modules is provided at the lowest path inclusion priority, the local team has a set of common modules at the next highest level of include priority, and then the dynamic environment has the highest level of inclusion priority. This allows for development and testing cases to be carried out through dynamic pulls of environment-labeled branches in git. Some form of regex matching of the environment to the configuration section, might help in this regard. In such a setup it would be nice to configure a puppet master as: <pre> [teama*] manifest = $confdir/environments/manifests/teamb/$environment/site.pp modulepath = $confdir/environments/modules/teamb/$environment/:$confdir/common/modules/teamb/:$confdir/common/modules/enterprise/ [teamb*] manifest = $confdir/environments/manifests/teama/$environment/site.pp modulepath = $confdir/environments/modules/teama/$environment/:$confdir/common/modules/teama/:$confdir/common/modules/enterprise/ </pre> ...or, alternatively.. such a case where the environment passed in is parsed within the configuration, allowing config-file variables to be set as such: <pre> [production] # passed in $environment = "team-production-product" $group = $environment.split("-")[0] # $releasecycle = $environment.split("-")[1] # $product = $environment.split("-")[2] manifest = $confdir/environments/manifests/$group/$environment/site.pp modulepath = $confdir/environments/modules/$group/$environment/:$confdir/common/modules/$group/:$confdir/common/modules/enterprise/ </pre> Within the base environments path, I would initialize the directory as a git repository and keep a post-receive wrapper script to dynamically fetch environments based on the $environment path. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
