saltstack / salt

Software to automate the management and configuration of any infrastructure or application at scale. Install Salt from the Salt package repositories here:
https://docs.saltproject.io/salt/install-guide/en/latest/
Apache License 2.0
14.19k stars 5.48k forks source link

[BUG] npm module __virtual__ takes 3 minutes to run when behind corporate firewall/proxy #59520

Open danieljennings opened 3 years ago

danieljennings commented 3 years ago

Description When the npm.py module loads via __virtual__, it executes the npm --version command:

https://github.com/saltstack/salt/blob/2d17209cafe51fdd00e4f6977fe8771385334ad3/salt/modules/npm.py#L39-L51

Per this bug (and my empirical experience) that command will take 3 minutes to run when behind a corporate firewall that prevents the "update notifier" from connecting to whatever web servers.

Because it's called from inside of the __virtual__, this causes any command that loads all of the modules (i.e. even an unrelated-to-NPM salt-call) to take 3+ minutes to run (and eventually timeout inside the update notifier).

The simplest fix would be to add the env var NO_UPDATE_NOTIFIER=1 to _check_valid_version's cmdmod.run call. I recognize that there are other npm commands inside of npm.py that will run into the same problem, but I'm particularly interested here because this behavior inside of a __virtual__ method is especially problematic due to running at module-load-time even if you don't use any of the NPM module features of Salt (since it's activated by virtue of just having an 'npm' executable found). There is supposedly a command line argument `--no-update-notifier' but I've seen reports online of it not working and have only confirmed that the environment variable fixes the problem.

I've included a version report but this behavior is seemingly common across all platforms.

Versions Report

salt --versions-report ``` Salt Version: Salt: 3002 Dependency Versions: cffi: 1.12.2 cherrypy: 17.4.1 dateutil: 2.8.0 docker-py: Not Installed gitdb: 2.0.5 gitpython: Not Installed Jinja2: 2.10.1 libgit2: Not Installed M2Crypto: Not Installed Mako: 1.0.7 msgpack-pure: Not Installed msgpack-python: 1.0.0 mysql-python: Not Installed pycparser: 2.19 pycrypto: Not Installed pycryptodome: 3.9.8 pygit2: Not Installed Python: 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] python-gnupg: 0.4.4 PyYAML: 5.3.1 PyZMQ: 18.0.1 smmap: 2.0.5 timelib: 0.2.4 Tornado: 4.5.3 ZMQ: 4.3.1 System Versions: dist: locale: cp1252 machine: AMD64 release: 2019Server system: Windows version: 2019Server 10.0.17763 SP0 ```
xeacott commented 3 years ago

Thank you for submitting this @danieljennings would you like to open a PR with your fix? Looked into it a bit, and it does appear that setting that var has fixed many others' issues.