My take on this is that I don't see it will affect my dynamic environment usage for my personal puppet environment as I'm using r10k fairly easily.
My deployment is available at https://github.com/UGNS/standard-modules and contains the modules deployed from a Puppetfile into the modules/ sub-directory but also contains a scripts/ and manifiests/ sub-directories so the only exception appears to be the scripts/ directory which for me contains my config version and autosigner scripts. Along with Jason my config version script takes the environment as an argument but given that the environment name is part of the path I could simply modify it to use the path rather than requiring an argument so long as we can still specify a config version script with path taken relative to the environment directory itself then it. On 02/21/2014 12:46 PM, Jason Antman wrote: > On 02/21/2014 11:53 AM, Andy Parker wrote: >> On Fri, Feb 21, 2014 at 5:13 AM, Jason Antman <ja...@jasonantman.com >> <mailto:ja...@jasonantman.com>> wrote: >> >> My heart stopped when I read this, though after reading the >> tickets, I think I'm a little more clear on it, and less concerned. >> >> >> Yes, all existing environments will continue to work in 3.5.0. The >> new environment system is still somewhat experimental in 3.5 and >> should be feature complete in 3.6. At that point the current >> environments will still work, but puppet will start issuing >> deprecations warnings. >> >> >> Just to confirm, the existing functionality will continue to work >> until the new directory-based environments are feature complete, >> correct? >> >> My specific concerns are around how I currently have environments >> configured; the salient parts are: >> modulepath = >> >> /etc/puppet/environments/$environment/modules:/etc/puppet/environments/$environment/modules-community >> i.e. I have 2 modulepaths within each environment >> >> >> The modulepath will be possible once we do PUP-1596. >> http://reviews.ddtc.cmgdigital.com/r/7402/ > Ok. Fair 'nuff. >> >> >> config_version = >> /etc/puppet/environments/$environment/config_version.sh $environment >> we have a Jenkins workflow wrapped around testing branches and >> promoting them through dev, test and prod. This is heavily >> dependent on all reports including config_version, which includes >> the current HEAD commit hash of the environment. >> >> >> Ok, I hadn't thought about that use of config_version (passing the >> environment as a parameter to the script). I was hoping to remove the >> $environment interpolation (PUP-1114) as a way to clearly move away >> from the current dynamic environment pattern, but maybe that won't be >> possible. > The output of our config_version script is "<environment name>/<full > git hash>". Passing $environment to config_version was, IIRC, a way to > make a portable config_version script that didn't have to "guess" the > environment from its current path. I suppose that if environments were > required to be in a given path, and config_version lived in that path, > it would be a non-issue. > > Thanks for replying and clearing that up. > > -Jason >> >> >> Thanks, >> Jason >> >> >> >> On 02/21/2014 03:41 AM, Joshua Partlow 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. >>> >>> -- 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/5307B20E.5090405%40UnderGrid.net. For more options, visit https://groups.google.com/groups/opt_out.
