[BUG] After upgrading to 3006.2 gitfs states 'remote ref does not exist' for ext_pillar #65002
Comments
|
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.
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. |
But with that said you say only one of your repos stopped working. So we need to try and find the conditions that causing the frailer. What OS are you on? |
|
@jonny08152 |
As stated above, we are using CentOS 9 Stream with
No this is the only time this repository is referenced.
The repository has
The only difference that stands out is the use of the
This was the first thing I tried but with no success. The error always stayed the same. Please note:
Just for the sake of completeness, here is our master config as a whole, maybe there is something I omitted earlier: Configinterface: 10.20.30.40
fileserver_backend:
- roots
- gitfs
jinja_env:
trim_blocks: True
lstrip_blocks: True
keep_trailing_newline: False
gitfs_provider: pygit2
gitfs_global_lock: False
gitfs_update_interval: 45
keep_jobs: 1
job_cache: False
minion_data_cache: False
gitfs_remotes:
- https://gitlab.com/my/salt-states.git:
- name: global
- root: global
- user: gitlab-deploy-token
- password: ********
- disable_saltenv_mapping: True
- saltenv:
- env-1:
- ref: master
- env-2:
- ref: master
...
- env-n:
- ref: master
- https://gitlab.com/my/salt-states.git:
- name: specific
- root: specific
- user: gitlab-deploy-token
- password: ********
- disable_saltenv_mapping: True
- saltenv:
- env-1:
- ref: master
- env-2:
- ref: dev
- https://gitlab.com/my-other/salt-states.git:
- name: other
- user: other-salt
- password: *********
- disable_saltenv_mapping: True
- saltenv:
- env-10:
- ref: main
- env-11:
- ref: feature
- env-12:
- ref: dev
...
ext_pillar_first: True
ext_pillar:
- git: # global: for all accounts and envs
- master https://gitlab.com/my/salt-pillar-global.git:
- all_saltenvs: master
- root: .
- user: gitlab-deploy-token
- password: *********
- env: __env__
- git: # specific: only for specific envs.
- __env__ https://gitlab.com/my/salt-pillar.git:
- root: .
- user: gitlab-deploy-token
- password: **********
- env: __env__
- fallback: master
- git:
- main https://gitlab.com/my-other/salt-pillar.git:
- root: .
- user: other-pillars
- password: ***********
- env: env-10
- git:
- main https://gitlab.com/my-other/salt-pillar.git:
- root: .
- user: other-pillars
- password: ***********
- env: env-11
- git:
- main https://gitlab.com/my-other/salt-pillar.git:
- root: .
- user: other-pillars
- password: ***********
- env: env-12
pillar_roots:
__env__:
- /srv/salt/pillar/global
pillar_safe_render_error: True
|
cmcmarrow
added
the
Confirmed
OrangeDog
added
the
Regression
|
Hi @jonny08152 I believe I got a fix for you. #65017 I would appreciate it if you give it a try and/or look. |
|
Hi @cmcmarrow , Unfortunately there is another error introduced by the fix. The master does not come up when using the following config (which is a subset of the original config from above for testing purposes): Configinterface: 10.20.30.40
fileserver_backend:
- roots
- gitfs
jinja_env:
trim_blocks: True
lstrip_blocks: True
keep_trailing_newline: False
gitfs_provider: pygit2
gitfs_global_lock: False
gitfs_update_interval: 15
keep_jobs_seconds: 180
job_cache: False
minion_data_cache: False
gitfs_remotes:
- https://gitlab.com/my/salt-states.git:
- name: global
- root: global
- user: gitlab-deploy-token
- password: ***********
- disable_saltenv_mapping: True
- saltenv:
- env-1:
- ref: master
- https://gitlab.com/my/salt-states.git:
- name: specific
- root: specific
- user: gitlab-deploy-token
- password: ***********
- disable_saltenv_mapping: True
- saltenv:
- env-1:
- ref: master
ext_pillar_first: True
ext_pillar:
- git: # global: for all accounts and envs
- master https://gitlab.com/my/salt-pillar.global.git:
- all_saltenvs: master
- root: .
- user: gitlab-deploy-token
- password: ***********
- env: __env__
- git: # specific: only for specific envs.
- __env__ https://gitlab.com/my/salt-pillar.git:
- root: .
- user: gitlab-deploy-token
- password: ***********
- env: __env__
- fallback: master
pillar_roots:
__env__:
- /srv/salt/pillar/global
pillar_safe_render_error: TrueThe master process does not start but instead prints the following error message: [WARNING ] Cache version mismatch clearing: '/var/cache/salt/master/gitfs'
[CRITICAL] The following gitfs remotes have conflicting cachedirs: https://gitlab.com/my/salt-states.git, https://gitlab.com/my/salt-states.git. Resolve this using a per-remote parameter called 'name'.
[WARNING ] Cache version mismatch clearing: '/var/cache/salt/master/git_pillar'
[CRITICAL] Failed to load gitfs
[CRITICAL] Master failed pre flight checks, exitingAs you can clearly see in the config, both remotes already have their name parameter set to distinct values. The Removing or commenting out one of the salt-state remotes lets the master come up and it then also serves the minions without errors. |
|
@jonny08152 thanks for testing |
|
@jonny08152 I believe to have fixed what you were seeing #65017 |
|
@cmcmarrow lgtm. I tested cmcmarrow@aba580f and got no errors anymore and the gitfs checkout also still working fine. |
|
@jonny08152 thank you so much for double checking. I'm going to close due to it being fixed. Feel free to open another ticket if you find another gitfs issue. |
Description
After upgrading our salt-masters from 3006.1 to 3006.2 the master is unable to checkout our ext_pillar git with the following error:
Downgrading the salt-master, salt-minion and salt packages back to 3006.1 immediately solves the issue.
Setup
Please be as specific as possible and give set-up details.
The masters run on a CentOS 9 Stream machine with the latest patches (see below).
Steps to Reproduce the behavior
This is the snipped from the master conf regarding the ext_pillar that causes the issue:
Running the master in debug mode prints the following:
The error message originates from this line of code:
salt/salt/utils/gitfs.py
Line 1799 in 8f750fa
Debugging showed the problem to be that there are no references retrieved at this point and such the
refslist being empty:salt/salt/utils/gitfs.py
Line 1632 in 8f750fa
We also reference other repositories in the ext_pillar block like this and they work fine.
Expected behavior
We expect the master to checkout the pillar repository without errors like in version 3006.1
Versions Report
salt --versions-report
Masters and Minions have the same version and also run on similarly configured VMs (same OS).The text was updated successfully, but these errors were encountered: