Issue #11900 has been updated by Nigel Kersten.
Mike McLane wrote: > Oh! I was unaware that the master detects changes in the conf and reloads the > config files. Does that reload just merge in new config sections, or replace > existing configuration? I am curious as to whether a reload might interrupt > a concurrent connection into a puppet master, while that config-refresh is > happening. Is the pupper master still susceptible to bad manifests bombing > the entire server? Seems like that might be an acceptable risk (everyone > should be lint testing their check-ins anyway, right?). It will reparse and replace the existing config. It will do that at the start of the next run, so you should be fine, but yes, I'd absolutely have a version control pre-commit hook that stops people checking in bad manifests or .erb templates. > So if that's the case -- yeah. We could add in a process to allow all > stakeholders to more or less auto-magically add their own environments/paths > to the puppet master, through revision control. We set up some automation to > fetch new conf bits, sync the modules/manifests to the puppet master visible > paths, apply the new environment into puppet.conf, and we're a-rockin. > > I believe this may satisfy what we're looking for. I'll start modeling some > proof of concepts on it. > > ..This could very well make for a solid presentation at a future PuppetConf. and we'd love to have you do it! Or even a blog post? I'm [email protected] and please feel free to ping me off-ticket if you want to have other chats about this approach. ---------------------------------------- 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.
