On Fri, Feb 21, 2014 at 8:15 AM, Spencer Krum <[email protected]>wrote:

> I want to echo Jason that I don't see how multiple module directories will
> work in this scheme. My modules go into two buckets 'internal' and 'public'.
>
> Can you describe that?
>
>
"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)"


> Thanks,
> Spencer
>
>
> On Fri, Feb 21, 2014 at 5:40 AM, Daniele Sluijters <
> [email protected]> wrote:
>
>> 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]
>>> 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].
>>>
>>> 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.
>>
>
>
>
> --
> Spencer Krum
> (619)-980-7820
>
> --
> 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/CADt6FWNm1cS_GXrsieVLtMfMZvKS7ngU14SvFC-4oud_YBrmfw%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Andrew Parker
[email protected]
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANhgQXu1W-Mud-fe1sCnFXHFSJ7mEEQZuMOhc%2BwKoqY6O%3DPLuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to