On Fri, Feb 21, 2014 at 2:41 AM, Joshua Partlow < joshua.part...@puppetlabs.com> wrote:
> Hi folks, > > (TL;DR: in 3.5.0+ environments will change to be named directories with a > specific structure and configurable defaults, all to be found in a > configured 'environmentpath') > > Andy, Henrik and I have been working on the new environment system > intended to eventually replace the current options for defining static and > dynamic environments with a single enumerable alternative. I'm going to > try and summarize where that work stands for 3.5.0 and what will be left > for 3.6.0. > > Prior to the new work, environments could be specified statically, > dynamically or by default in the following three ways: > > Static environments could be explicitly set as sections in puppet.conf, > where the section name was the environment name and certain settings in > that section would take priority over main, run mode or application default > settings if puppet's main environment setting had been set to match, yet in > turn be over ridden by command line settings. The settings which have an > effect within a static environment section are 'modulepath', 'manifest', > 'templatedir', and 'config_version'. > > Dynamic environments could be set by including $environment for > interpolation in these key settings, for instance in the [main] > 'modulepath' and 'manifest' settings. > > And the default case is simply the default 'environment' (production) and > the default 'modulepath' and 'manifest' settings. > > Starting in Puppet 3.5.0 we are adding a new way of specifying > environments which allows both for explicit enumeration of existing > environments and dynamic addition of environments without adjusting the > master configuration. In this system each environment will simply be a > directory with a specific structure located in a given path. Hence we are > calling them directory environments for now to distinguish them from their > legacy kin. > > The new system relies on a new setting 'environmentpath' in puppet.conf. > The 'environmentpath' may be set to one or more directories that will be > searched for environment directories. Its default is > "$confdir/environments". > > Each directory in the path may contain a number of subdirectories, one for > each environment, where the name of the subdirectory is the name of the > environment (valid environment names match the regular expression /\w+/). > Inside each environment's directory there are two more directories: > `modules` for environment specific modules and `manifests` for the > environment's manifests (this is where `site.pp` would be placed). > > environments > |- my_env > | |- modules > | | \- stdlib > | \- manifests > | \- site.pp > ... > > If your 'environmentpath' setting contains multiple directories, then an > environment will be matched from the first path directory it can be located > in. So environments found earlier in the path will shadow environments > that are located later in the path. > > In addition, there is a new setting 'basemodulepath' which is intended to > provide a path to global modules available across all environments. It has > the same defaults as the current [main] 'modulepath' setting > "$confdir/modules:/usr/share/puppet/modules", and 'modulepath' now defaults > to "$basemodulepath". > > This setting is appended to each directory environment's modulepath. So > for the above 'my_env' example, its modulepath would be > "$confdir/environments/my_env/modules:$basemodulepath". > > In 3.5.0, the 'basemodulepath' setting can be interpolated into other > legacy environments as well. > > The new directory environments will be functional as described above, but > not feature complete in 3.5.0. The plan is to finish them in 3.6.0, and > deprecate static, dynamic and the default environment settings, which will > then be removed in 4.0. > > The main directory environment feature scheduled to be added in 3.6.0 is > to allow for a per environment configuration file that can customize > modulepath and manifest directory settings within each directory > environment. This would be in the form of an environment.conf file, > following the same format as puppet.conf. In addition to setting > 'modulepath' and 'manifest', 'config_version' could be set here as well. > This should give parity to the current static environment sections in > puppet.conf. (https://jira.puppetlabs.com/browse/PUP-1596) > > In 3.6.0, [main] 'modulepath', 'manifest', 'config_version' would be > deprecated. The default manifest would be found in > "$confdir/environments/production/manifests/site.pp", and packaging would > be modified to construct this base default environment. Use of static > environment sections and interpolating $environment within puppet.conf > would be deprecated as well. > > You can also enumerate the new directory environments via the v2.0 API > endpoint (/v2.0/environments) that Andy and Dan worked on. (see > https://github.com/puppetlabs/puppet/blob/master/api/docs/http_environments.md) > Command line enumeration of environments is targeted for 4.0. > > The epic for the environment work is: > https://jira.puppetlabs.com/browse/PUP-536 > > Please let me know if I made any mistakes about existing functionality, or > you have any questions or suggestions for us with regards to the directory > environments. > > thanks, > Josh P. > > -- > Josh Partlow > jpart...@puppetlabs.com > Developer, Puppet Labs > > Join us at PuppetConf 2014, September 23-24 in San Francisco - > http://bit.ly/pupconf14 > Register now and save $350! > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CADxAQ5pzqpo20nuLY5LxFzrEf53V_m-8wYHNq9%2BCvo1T1b-Arw%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > Hi Josh/Andy/Henrik, Could you please provide some background on why this change is being made, and what the benefits to the user will be? If this is just to make it easier to support future APIs, I'm curious to know why we need to change the UI. Thanks, - James -- James Sweeny Professional Services http://puppetlabs.com/ *Join us at PuppetConf 2014, September 23-24 in San Francisco - * http://bit.ly/pupconf14 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAKDACKtqykjQnJEJzFMO%2B8du%3D-AOwRiU9V-jKJrFceb0m1Hb%3DA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
