-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Master cannot see minion after 2018.3.0 upgrade #47905
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I have not been able to replicate this in our package testing. When you say its failing what is occurring? Are you seeing an error? Also do you see anything in the debug log on the master o minion side when this occurs? When the master sends the command do you see network traffic occurring on the minion? possibly using tcpdump? Can you paste |
Sorry when I say it fails it returns
|
version reports is Salt Version: Dependency Versions: System Versions: |
The ping with debug output from the master outputs
I am surprise to see 127.0.0.1 as address, but that's the same output with a machine which works. |
The machine also receives TCP packets from the master, every second or so
|
And that's running a ping FROM the machine, which succeeds and adds the machine to the master key list, although doesn't fix the problem from the master, i.e. still cannot ping the minion
|
Ok I finally got down to the bottom of the problem after outputting the daemon errors to a file, so the problem is that on those clean machines there is no Git installed.
So it's not related to the version although the previous version doesn't seem to have this problem. |
Ok well looking at the code it looks like it just tries to import git and capture an exception but not this one, so it should just be a matter of capturing the GitCommandError too. |
@maxime-viargues-serato Yeah, the problem with that is that we can't capture that error directly because it's part of an exception class in GitPython itself. @Ch3LL is going to change the exception catching to a general This is actually being caused by an upstream bug in GitPython. I reported and fixed this last year in gitpython-developers/GitPython#658, but this fix only worked when the I've reported this upstream and opened gitpython-developers/GitPython#763 to fix it. In the meantime, like I said, @Ch3LL is going to work around this by changing the exception catching. Thanks for reporting! |
I am seeing the same thing with windows minions that I just upgraded to 2018.3 |
Thanks @terminalmage I'll wait for the fix and use the 2017 version in the meantime. |
@prog-dale I just had a similar issue. Have you tried restarting the salt-minion. For me, it worked after doing that. Digging through the event logs, I got this:
for some reason, and after that, the minion has been technically on, able to run |
2018.3.3 contains @Ch3LL's workaround for this upstream bug, and GitPython 2.1.11 contains my fix for the upstream bug. Given both of these facts, I am going to close this. |
Hi, ll /etc/salt/pki/minion/minion_master.pub salt-minion --versionsalt-minion 2018.3.3 (Oxygen) so you need to remove salt-minion, delete master.pub and reinstall. |
Description of Issue/Question
On MacOS the latest minion 2018.3.0 is not recognised by the master.
We are were using salt with 2017.7.2 on both master and minions on both MacOS and Windows, then upgraded the master to 2018.3.0. All the currently set-up machines are still working fine. We upgraded the Windows machines to 2018.3.0, all good. Mac machines are still on 2017.7.2.
Now we are setting up new MacOS machines and found that using the latest minion 2018.3.0 doesn't connect to the master anymore, but previous version 2017.7.2 does work.
Setup
MacOS El capitan
Steps to Reproduce Issue
The way the machine is setup is simply:
We have the auto-accept option on master so after that, the machine is normally added automatically to the key list and works.
Now with the latest version, we install the new package (from a clean machine), run the same salt-config, but the machine is not added to the master key list nor visible.
If running a
salt-call test.ping
from the machine, then the machine is accepted on the master and can successfully apply a state. However, calling any command from the master, even asalt 'machine' test.ping
, will fail.The master can successfully ping the machine with a normal
ping ip.address
It looks like the minion can access the master fine and do transaction (the master sending information too), but the master cannot see the minion by itself.
Versions Report
salt 2018.3.0 (Oxygen)
root@saltstack:/srv/salt# salt --versions-report
Salt Version:
Salt: 2018.3.0
Dependency Versions:
cffi: Not Installed
cherrypy: Not Installed
dateutil: 2.4.2
docker-py: Not Installed
gitdb: 0.6.4
gitpython: 1.0.1
ioflo: Not Installed
Jinja2: 2.8
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: Not Installed
Mako: 1.0.3
msgpack-pure: Not Installed
msgpack-python: 0.4.6
mysql-python: Not Installed
pycparser: Not Installed
pycrypto: 2.6.1
pycryptodome: Not Installed
pygit2: Not Installed
Python: 2.7.12 (default, Dec 4 2017, 14:50:18)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 15.2.0
RAET: Not Installed
smmap: 0.9.0
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.4
System Versions:
dist: Ubuntu 16.04 xenial
locale: UTF-8
machine: x86_64
release: 4.4.0-127-generic
system: Linux
version: Ubuntu 16.04 xenial
The text was updated successfully, but these errors were encountered: