Salt: please add a salt-ssh --bootstrap

[bmwiedemann]

Description of Issue/Question

Originally filed at https://bugzilla.opensuse.org/show_bug.cgi?id=1057772

Setup

have a remote node without python installed

Steps to Reproduce Issue

run salt-ssh $NODENAME test.ping

This will fail due to lack of python on the remote node.

Versions Report

Salt: 2017.7.2

Thoughts

One nice solution could be a new salt-ssh --bootstrap $NODENAME
that translates to something like

salt-ssh $NODENAME -r '
  if grep -q "SUSE" /etc/os-release ; then 
    zypper -n in python python-xml ;
  elif [ -e /etc/debian_version ] ; then 
    apt install ... ;
  else
    echo "please add support for your OS to salt-ssh bootstrap"
  fi'

[Ch3LL]

hmmm so you want salt-ssh to install python if its not available? I'm not so sure we would want to add this as it would require a lot of hardcoded management. ping @saltstack/team-core any opinions here?Maybe instead we could setup a feature in salt-ssh where we have raw pre_flight commands and the user can control what is run before salt-ssh is run?

As a side note you can just run a raw salt-ssh command to install it salt-ssh '*' -r "zypper -n in python python-xml".

[bmwiedemann]

It does not need to check for python with every salt-ssh run as that would impose overhead, but when I know that I just added some nodes (could also be heterogenous so some openSUSE, Debian, Archlinux and Fedora) then I just want to say salt-ssh --bootstrap '*'

What 'hardcoded management' do you have in mind, other than knowing how to pull in the runtime dependencies of salt-ssh via a salt-ssh -r run?

If salt only supported 10 of 13 possible distros, it would still be an improvement, because the others can still use salt-ssh -r like before

[isbm]

@bmwiedemann
I am not sure we want this, as it will end up with some sort of pkg.install trimmed remake in Bash that would attempt to bootstrap minimum requirements (and will fail elsewhere). You example isn't any heterogeneous, but mono-diverse, if I can express it right: you're just enumerating various "Linuxes", omitting everything else. But from the Salt perspective this is not right. Please keep in mind that this should support not just particular Linux distros, yet many other OSes, like Solaris, Windows, OSX, BSD etc...

So I am not really sure we want this, as a basic Python installation is a firm requirement here. The same applies to Ansible, so why Salt should be any different?

Also, @Ch3LL already gave you a workaround that would solve the issues in your particular use-case. From my views and perspective this issue can be closed.

@gtmanfred @cachedout @terminalmage opinions?

[piec]

I agree a bootstrap method would be nice.
salt-ssh also requires python-concurrent.futures on the target machine now, because tornado requires it.

salt-ssh -i <machine> test.ping fails on a fresh debian installation + python2
Installing python-concurrent.futures on the target machine solves the exception.

---

Sample output

% salt-ssh -i <machine> test.ping
titan:
    ----------
    retcode:
        0
    stderr:
        Traceback (most recent call last):
          File "/var/tmp/.it_d4e38f_salt/salt-call", line 15, in <module>
            salt_call()
          File "/var/tmp/.it_d4e38f_salt/py2/salt/scripts.py", line 395, in salt_call
            import salt.cli.call
          File "/var/tmp/.it_d4e38f_salt/py2/salt/cli/call.py", line 5, in <module>
            import salt.utils.parsers
          File "/var/tmp/.it_d4e38f_salt/py2/salt/utils/parsers.py", line 27, in <module>
            import salt.config as config
          File "/var/tmp/.it_d4e38f_salt/py2/salt/config/__init__.py", line 98, in <module>
            _DFLT_IPC_WBUFFER = _gather_buffer_space() * .5
          File "/var/tmp/.it_d4e38f_salt/py2/salt/config/__init__.py", line 88, in _gather_buffer_space
            import salt.grains.core
          File "/var/tmp/.it_d4e38f_salt/py2/salt/grains/core.py", line 44, in <module>
            import salt.utils.dns
          File "/var/tmp/.it_d4e38f_salt/py2/salt/utils/dns.py", line 32, in <module>
            import salt.modules.cmdmod
          File "/var/tmp/.it_d4e38f_salt/py2/salt/modules/cmdmod.py", line 34, in <module>
            import salt.utils.templates
          File "/var/tmp/.it_d4e38f_salt/py2/salt/utils/templates.py", line 32, in <module>
            import salt.utils.http
          File "/var/tmp/.it_d4e38f_salt/py2/salt/utils/http.py", line 41, in <module>
            import salt.loader
          File "/var/tmp/.it_d4e38f_salt/py2/salt/loader.py", line 28, in <module>
            import salt.utils.event
          File "/var/tmp/.it_d4e38f_salt/py2/salt/utils/event.py", line 85, in <module>
            import salt.transport.ipc
          File "/var/tmp/.it_d4e38f_salt/py2/salt/transport/ipc.py", line 21, in <module>
            from tornado.locks import Semaphore
          File "/var/tmp/.it_d4e38f_salt/py2/tornado/locks.py", line 18, in <module>
            from concurrent.futures import CancelledError
        ImportError: No module named concurrent.futures
    stdout:

[jjongbloets]

For me, this is a significant issue as well.

I do not think this issue would be so hard to implement as most of it is already available in the salt bootstrap script. The problem with this script is, however, that it does not allow users to install dependencies without minion or server. I just tried to run the script with the "-N" parameter and it just warns you there is "nothing" to install. If this could be change it would be a huge improvement.

My current workaround is to bootstrap with the regular bootstrap script via salt-ssh -r and the "-X" argument and then having a salt state to remove the minion. But this defies the logic of salt-ssh which should not require a minion to be installed on the node in the first place.....

[isbm]

@piec This is just a bug. It was fixed already. I have to check if that went to the package update though. BTW, this is problem only when your target is expected on Python 2.x while on Python 3.x this doesn't happen.

[devurandom]

@piec This is just a bug. It was fixed already.

I confirm. Salt 2018.3.2 as shipped by Fedora 29 is affected by this bug. Updating to 2019.2.0 fixes the issue for me.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.