Hey,

As far as I can see I see no reason why your setup wouldn't work, at least 
not once it's feature complete in 3.6.0.

All in all, this sounds great to me!

-- 
Daniele Sluijters

On Friday, 21 February 2014 14:13:59 UTC+1, Jason Antman 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.
>
> 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
>    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.
>
> 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.
>
>  -- 
> Josh Partlow 
> [email protected] <javascript:>
> 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 [email protected] <javascript:>.
> 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.
>
>
>  

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/7d0ae273-1ceb-44f3-9797-ed4289026db3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to