salt.pillar.git_pillar¶

Use a git repository as a Pillar source¶

Note

This external pillar has been rewritten for the 2015.8.0 release. The old method of configuring this external pillar will be maintained for a couple releases, allowing time for configurations to be updated to reflect the new usage.

This external pillar allows for a Pillar top file and Pillar SLS files to be sourced from a git repository.

However, since git_pillar does not have an equivalent to the pillar_roots parameter, configuration is slightly different. The Pillar top file must still contain the relevant environment, like so:

base:
  '*':
    - foo

The branch/tag which maps to that environment must then be specified along with the repo's URL. Configuration details can be found below.

Configuring git_pillar for Salt releases before 2015.8.0¶

For Salt releases earlier than 2015.8.0, GitPython is the only supported provider for git_pillar. Individual repositories can be configured under the ext_pillar configuration parameter like so:

ext_pillar:
  - git: master https://gitserver/git-pillar.git root=subdirectory

The repository is specified in the format <branch> <repo_url>, with an optional root parameter (added in the 2014.7.0 release) which allows the pillar SLS files to be served up from a subdirectory (similar to gitfs_root in gitfs).

To use more than one branch from the same repo, multiple lines must be specified under ext_pillar:

ext_pillar:
  - git: master https://gitserver/git-pillar.git
  - git: dev https://gitserver/git-pillar.git

To remap a specific branch to a specific Pillar environment, use the format <branch>:<env>:

ext_pillar:
  - git: develop:dev https://gitserver/git-pillar.git
  - git: master:prod https://gitserver/git-pillar.git

In this case, the develop branch would need its own top.sls with a dev section in it, like this:

dev:
  '*':
    - bar

The master branch would need its own top.sls with a prod section in it:

prod:
  '*':
    - bar

If __env__ is specified as the branch name, then git_pillar will use the branch specified by gitfs_base:

ext_pillar:
  - git: __env__ https://gitserver/git-pillar.git root=pillar

The corresponding Pillar top file would look like this:

{{env}}:
  '*':
    - bar

Configuring git_pillar for Salt releases 2015.8.0 and later¶

Beginning with Salt version 2015.8.0, pygit2 is now supported for git_pillar, in addition to GitPython (Dulwich will not be supported for the forseeable future). The requirements for GitPython and pygit2 are the same as for gitfs, as described here.

Here is an example git_pillar configuration.

ext_pillar:
  - git:
    - production https://gitserver/git-pillar.git:
      - env: prod
    - develop https://gitserver/git-pillar.git:
      - env: dev
    - qa https://gitserver/git-pillar.git
    - master https://other-git-server/pillardata.git
      - root: pillar

The main difference between this and the old way of configuring git_pillar is that multiple remotes can be configured under one git section under ext_pillar. More than one git section can be used, but it is not necessary. Remotes will be evaluated sequentially.

Per-remote configuration parameters are supported (similar to gitfs), and global versions of the git_pillar configuration parameters can also be set.

With the addition of pygit2 support, git_pillar can now interact with authenticated remotes. Authentication works just like in gitfs (as outlined in the GitFS Walkthrough), only with the global authenication parameter names prefixed with git_pillar instead of gitfs (e.g. git_pillar_pubkey, git_pillar_privkey, git_pillar_passphrase, etc.).

A full list of the git_pillar configuration options can be found here.

class salt.pillar.git_pillar.LegacyGitPillar(branch, repo_location, opts)¶

Deal with the remote git repository for Pillar

envs()¶: Return a list of refs that can be used as environments

map_branch(branch, opts=None)¶

update()¶

Ensure you are following the latest changes on the remote

Return boolean whether it worked

salt.pillar.git_pillar.ext_pillar(minion_id, repo, pillar_dirs)¶: Execute a command and read the output as YAML