You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
We have multimaster setup with the same configuration on both masters.
Looks like salt master continues to not respect pillarenv's (while another master continues to do so). It does however respect saltenv aka will look at alternative branches for state files (just not pillar).
We have tried:
Rebuilding the entire salt-master.
Using both gitpython and libgit2 git libraries for the gitfs backend.
Downgrading gitpython versions
The impact is that regardless of what you specify as pillarenv= when applying states or fetching pillar entries, it always fetches from the master branch.
Setup
Both masters are on Almalinux8
For gitfs we have configured
gpg_keydir: /etc/salt/master.d/gpgkeys
top_file_merging_strategy: same
state_top_saltenv: base
fileserver_backend:
- roots
- git
file_roots:
base:
- /srv/salt
# - set salt states gitfs
gitfs_provider: gitpython
gitfs_remotes:
- ssh://git@github.<redacted>/salt.git
# - set salt pillar gitfs
git_pillar_provider: gitpython
ext_pillar:
- git:
- __env__ ssh://git@github.<redacted>/salt.git:
- root: pillar
# the pillarenv value will assume the value of the effective saltenv when running states.
pillarenv_from_saltenv: true
For minions we have:
log_file: /var/log/salt/minion
#to prevent the minion from setting itself back to default base environment which is the master branch.
default_top: nonexistent_branch
master_shuffle: True
verify_master_pubkey_sign: True
master:
- salt-master1
- salt-master2
Steps to Reproduce the behavior
When we run command like this
salt 'test-minion' pillar.item ceph_release_codename pillarenv=some_test_env
we get the different output on both masters
on salt-master1
Hi there! Welcome to the Salt Community! Thank you for making your first contribution. We have a lengthy process for issues and PRs. Someone from the Core Team will follow up as soon as possible. In the meantime, here’s some information that may help as you continue your Salt journey.
Please be sure to review our Code of Conduct. Also, check out some of our community resources including:
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Community Events Calendar.
If you have additional questions, email us at saltproject@vmware.com. We’re glad you’ve joined our community and look forward to doing awesome things with you!
Description
We have multimaster setup with the same configuration on both masters.
Looks like salt master continues to not respect pillarenv's (while another master continues to do so). It does however respect saltenv aka will look at alternative branches for state files (just not pillar).
We have tried:
Rebuilding the entire salt-master.
Using both gitpython and libgit2 git libraries for the gitfs backend.
Downgrading gitpython versions
The impact is that regardless of what you specify as pillarenv= when applying states or fetching pillar entries, it always fetches from the master branch.
Setup
Both masters are on Almalinux8
For gitfs we have configured
For minions we have:
Steps to Reproduce the behavior
When we run command like this
we get the different output on both masters
on salt-master1
on salt-master2
minion log on working master
minion log with problematic master
If we compare the output on the working master it creates only one jid, while on the second master it creates two
Expected behavior
The valid output on both masters should be
Screenshots
If applicable, add screenshots to help explain your problem.
Versions Report
master1
master2
Additional context
None
The text was updated successfully, but these errors were encountered: