2

I've setup git on an nfs server. The salt master auto-mounts the folder containing the git repository on boot. I have copied .sls files, templates and scripts to the git directory and added them to git.

I have added the following to the master config file, according to the guide here:

fileserver_backend:
  - git

gitfs_remotes:
  - file:///mnt/git-repo

I am in doubt about what to set file_roots to, but have tried both 

- /srv/salt

and

- /mnt/git-repo

with same result: "No Top file or external nodes data matches found"

SaltStack version is 0.17.4, OS is SLES 11.2.

Does anyone know where I have gone wrong?

Marmoy
  • 8,009
  • 7
  • 46
  • 74
  • Not trying to insult you, but could you confirm that there is a /mnt/git-repo/top.sls? Can you also confirm that the user you are using to run salt (root by default) can pull from that repo via ssh (e.g. git clone ssh://gitrepoip)? – Jason Zhu Jan 20 '14 at 18:58
  • You don't need to set `file_roots` if you're using gitfs. Additionally, when you use a `file://` prefix on a `gitfs_remote`, note that it will still clone that repository, so that repository needs to either be a bare repo, or the path needs to point to the `.git` folder inside of the repo. Basically, the command `git clone ` needs to work outside of salt. Once you have that setup, you should run `salt 'myminion' cp.list_master` to make sure the repo is actually making it into the cache. – Colton Myers Jan 20 '14 at 23:27

6 Answers6

1

Improper configuration

This section was improper for me since I didn't have anything on local filesystem.

fileserver_backend:
  - git
  - roots

I changed it to:

fileserver_backend:
  - git

Missing GitPython

easy_install GitPython

wrong configuration (GitPython vs pygit2)

My configuration was:

gitfs_provider: gitpython
gitfs_remotes:
  - ssh://git.example.com/salt-states.git:
    - pubkey: /root/.ssh/id_rsa.pub
    - privkey: /root/.ssh/id_rsa

But looking at the logs, tail /var/log/salt/master :

2015-02-24 14:25:37,162 [salt.loaded.int.fileserver.gitfs ][CRITICAL] GitFS authentication parameter 'privkey' (from remote ssh://git.example.com/salt-states.git) is only supported by the following provider(s): pygit2. Current gitfs_provider is 'gitpython'. See the GitFS Walkthrough in the Salt documentation for further information.

gitfs_provider: gitpython
gitfs_remotes:
  - ssh://git.example.com/salt-states.git

Everything else (IdentityFile) is specified in /root/.ssh/config.

Cache is polluted

I had leftover data from previous experiments; so I had to clean the cache:

rm -rf /var/cache/salt/*

dnozay
  • 23,846
  • 6
  • 82
  • 104
0

Ensure that you have a top.sls file in the root of your master branch and that you've restarted the salt-master daemon after modifying the master config file.

Utah_Dave
  • 4,531
  • 24
  • 23
0

What solve this issue for me actually was salt-master package upgrade, seems that their api got somehow icompatible between version, so newer salt-minion installed wasn't syncing file_roots properly.

elmariofredo
  • 717
  • 7
  • 7
0

It could be that you're trying to use a mount point and file roots in two different locations. I had a similar problem a while ago: SaltStack and GitFS - No Top file or external nodes data matches found

My fix was to remove the mount.

Community
  • 1
  • 1
Kryten
  • 595
  • 3
  • 10
  • 25
0

I've faced this issue when using a wrong jinja command inside a comment in the top file. Make sure to have a look in the logs of the minion.

Related issue that I opened: https://github.com/saltstack/salt/issues/47612

Alberto Chiusole
  • 2,204
  • 2
  • 16
  • 26
-1

Cloning the repository gave the following message "Warning: You appear to have cloned an empty repository". (thanks @Jason Zhu) It did this because although the files were added to the repository, they were not committed.

To solve the problem I:

  1. removed file_roots from the master config file, since it is not needed when you use gitfs (thanks @basepi)

  2. restarted the salt-master, to enforce changes to master config file (thanks @Utah_Dave)

  3. committed the added files to the repository

Marmoy
  • 8,009
  • 7
  • 46
  • 74