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.
--
Josh Partlow
jpart...@puppetlabs.com <mailto: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
<mailto: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.
--
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
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/53075117.3060708%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Andrew Parker
a...@puppetlabs.com <mailto:a...@puppetlabs.com>
Freenode: zaphod42
Twitter: @aparker42
Software Developer
*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/CANhgQXu0p3hHYrEeJy6i6gyePOQa5uPOhi3rOGvht6WyKwa9OA%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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/5307910C.2020300%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.
