Hi Eric.
Such behavior cold be possible if both salt-minion and venv-salt-minion are installed on the system, but only salt-minion is configured to the sarver.
In this case on highstate apply, venv-salt-minion will be configured to the server as is's the preferred one, but the salt-minion left untouched.
In general it looks like it could happen on the testsuite, but not so common case for the real systems as we recommmed to apply the migration state to migrate to venv-salt-minion and it's disabling the salt-minion after configuring the bundle.
Victor
From: Eric Bischoff <EBischoff@suse.com>
Sent: Thursday, May 5, 2022 7:16:03 PM
To: General discussion related to the openSUSE Uyuni project <users@lists.uyuni-project.org>
Cc: McGranahan, Jamen (VU) <jamen.mcgranahan@vanderbilt.edu>; Victor Zhestkov <Victor.Zhestkov@suse.com>; Bidault, Philippe <Philippe.Bidault@getronics.com>; Bidault, Philippe via Uyuni Users <users@lists.uyuni-project.org>
Subject: Re: Salt ID continues to return
Le jeudi 5 mai 2022, 17:29:39 CEST Bidault, Philippe via Uyuni Users a écrit :
> And it is probably keeping reappearing because the salt agent is still
> running on your server libvm29 and keep requesting for a key to the Salt
> server. Just stop/remove the salt minion on it to prevent for the pending
> key to appear again and before trying to register it again.
I have had recently a very similar issue, and the cause was that I had both
"salt-minion" and "venv-salt" running at same time.
No matter how much I was accepting or rejecting the keys, they kept arriving.
Solution was to directly delete the associated process on the minion and to
keep only one of both services running.
Best,
--
Eric Bischoff - SUSE Manager QA Engineer
SUSE Software Solutions Germany GmbH (HRB 36809, AG Nürnberg)
Managing Director/Geschäftsführer: Ivo Totev