valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-07 17:09:03 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #37721 from terminalmage/zd909

Browse Source 
Fix for pillar setting 'environment' key in __gen_opts()
This commit is contained in:
Thomas S Hatch 2016-11-16 09:04:53 -07:00 committed by GitHub
commit 35655d521f
2 changed files with 26 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
salt/pillar/__init__.py
View File

@ -348,7 +348,7 @@ class Pillar(object):
opts['grains'] = {} opts['grains'] = {}
else: else:
opts['grains'] = grains opts['grains'] = grains
if 'environment' not in opts: if not opts.get('environment'):
opts['environment'] = saltenv opts['environment'] = saltenv
opts['id'] = self.minion_id opts['id'] = self.minion_id
if 'pillarenv' not in opts: if 'pillarenv' not in opts:

34
salt/pillar/git_pillar.py
View File

@ -109,8 +109,9 @@ it:
'*': '*':
- bar - bar
If ``__env__`` is specified as the branch name, then git_pillar will use the If ``__env__`` is specified as the branch name, then git_pillar will first look
branch specified by :conf_master:`gitfs_base`: at the minion's :conf_minion:`environment` option. If unset, it will fall back
to using branch specified by the master's :conf_master:`gitfs_base`:
.. code-block:: yaml .. code-block:: yaml
@ -133,6 +134,11 @@ The corresponding Pillar top file would look like this:
described above. For 2016.3.4 and later, refer to explanation of the described above. For 2016.3.4 and later, refer to explanation of the
``__env__`` parameter in the below section. ``__env__`` parameter in the below section.
Versions 2016.3.0 through 2016.3.4 incorrectly check the *master's*
``environment`` config option (instead of the minion's) before falling back
to :conf_master:`gitfs_base`. This has been fixed in the 2016.3.5 and
2016.11.1 releases (2016.11.0 contains the incorrect behavior).
.. _git-pillar-2015-8-0-and-later: .. _git-pillar-2015-8-0-and-later:
Configuring git_pillar for Salt releases 2015.8.0 and later Configuring git_pillar for Salt releases 2015.8.0 and later
@ -233,15 +239,25 @@ The corresponding Pillar top file would look like this:
.. note:: .. note::
This feature was unintentionally omitted when git_pillar was rewritten for This feature was unintentionally omitted when git_pillar was rewritten for
the 2015.8.0 release. It was added again in the 2016.3.4 release, but it the 2015.8.0 release. It was added again in the 2016.3.4 release, but it
has changed slightly in that release. On Salt masters running 2015.8.0 has changed slightly in that release. The fallback value replaced by
through 2016.3.3, this feature can only be accessed using the legacy config ``{{env}}`` is :conf_master: is :conf_master:`git_pillar_base`, while the
in the previous section of this page. legacy config's version of this feature replaces ``{{env}}`` with
For 2016.3.4 and later, the above example is accurate, and the value
replaced by ``__env__`` is :conf_master:`git_pillar_base`, while the legacy
config's version of this feature replaces ``__env__`` with
:conf_master:`gitfs_base`. :conf_master:`gitfs_base`.
On Salt masters running 2015.8.0 through 2016.3.3, this feature can only be
accessed using the legacy config in the previous section of this page.
The same issue which affected the behavior of the minion's
:conf_minion:`environment` config value using the legacy configuration
syntax (see the documentation in the pre-2015.8.0 section above for the
legacy support of this feature) also affects the new-style git_pillar
syntax in version 2016.3.4. This has been corrected in version 2016.3.5 and
2016.11.1 (2016.11.0 contains the incorrect behavior).
2016.3.4 incorrectly checks the *master's* ``environment`` config option
(instead of the minion's) before falling back to the master's
:conf_master:`git_pillar_base`.
With the addition of pygit2_ support, git_pillar can now interact with With the addition of pygit2_ support, git_pillar can now interact with
authenticated remotes. Authentication works just like in gitfs (as outlined in authenticated remotes. Authentication works just like in gitfs (as outlined in
the :ref:`Git Fileserver Backend Walkthrough <gitfs-authentication>`), only the :ref:`Git Fileserver Backend Walkthrough <gitfs-authentication>`), only