From 433737d2dcd1bc56991b1ee3171ca6d10398e73f Mon Sep 17 00:00:00 2001 From: Erik Johnson Date: Wed, 16 Nov 2016 01:10:54 -0600 Subject: [PATCH 1/2] Fix for pillar setting 'environment' key in __gen_opts() 7a6e402 added ``environment`` as a key in the master opts. This had the unfortunate side effect of breaking the dynamic pillar feature in git_pillar, which relies on pillar setting this opts key to the value from the minion opts. --- salt/pillar/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/salt/pillar/__init__.py b/salt/pillar/__init__.py index f75aaecddb..35faa3cdf3 100644 --- a/salt/pillar/__init__.py +++ b/salt/pillar/__init__.py @@ -348,7 +348,7 @@ class Pillar(object): opts['grains'] = {} else: opts['grains'] = grains - if 'environment' not in opts: + if not opts.get('environment'): opts['environment'] = saltenv opts['id'] = self.minion_id if 'pillarenv' not in opts: From acdd5513daf7836ef21c6f6055e466386049b733 Mon Sep 17 00:00:00 2001 From: Erik Johnson Date: Wed, 16 Nov 2016 01:41:20 -0600 Subject: [PATCH 2/2] Update git_pillar docs to reflect info from bugfix --- salt/pillar/git_pillar.py | 34 +++++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/salt/pillar/git_pillar.py b/salt/pillar/git_pillar.py index 4bc6dfd8fc..a7654fd96a 100644 --- a/salt/pillar/git_pillar.py +++ b/salt/pillar/git_pillar.py @@ -109,8 +109,9 @@ it: '*': - bar -If ``__env__`` is specified as the branch name, then git_pillar will use the -branch specified by :conf_master:`gitfs_base`: +If ``__env__`` is specified as the branch name, then git_pillar will first look +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 @@ -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 ``__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: 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:: 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 - has changed slightly in that release. 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. - - 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 + has changed slightly in that release. The fallback value replaced by + ``{{env}}`` is :conf_master: is :conf_master:`git_pillar_base`, while the + legacy config's version of this feature replaces ``{{env}}`` with :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 authenticated remotes. Authentication works just like in gitfs (as outlined in the :ref:`Git Fileserver Backend Walkthrough `), only