Page MenuHomePhabricator

Stretch vs. Salt
Closed, InvalidPublic

Description

I'm trying to install the standard version of the salt minion on a stretch box (version 2014.7.5+ds-1+wm2, which I copied into the stretch repo).

I get crazy dependency complaints for packages which are clearly already installed:

root@stretchlvm:~# apt-get install salt-common salt-minion
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 salt-common : Depends: python but it is not going to be installed
               Depends: python:any (< 2.8)
               Depends: python:any (>= 2.7.5-5~)
               Depends: python-dateutil but it is not going to be installed
               Depends: python-jinja2 but it is not going to be installed
               Depends: python-apt but it is not going to be installed
               Depends: python-yaml but it is not going to be installed
               Depends: python-pkg-resources but it is not going to be installed
               Depends: python-requests (>= 1.0.0) but it is not going to be installed
 salt-minion : Depends: python but it is not going to be installed
               Depends: python:any (>= 2.6~)
               Depends: python-m2crypto but it is not going to be installed
               Depends: python-crypto but it is not going to be installed
               Depends: python-msgpack but it is not going to be installed
               Depends: python-zmq (>= 13.1.0) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Event Timeline

Andrew created this task.May 5 2017, 4:07 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 5 2017, 4:07 PM
Paladox added a subscriber: Paladox.May 5 2017, 4:08 PM
Andrew updated the task description. (Show Details)May 5 2017, 4:08 PM
Andrew updated the task description. (Show Details)May 5 2017, 4:11 PM
Paladox added a comment.EditedMay 5 2017, 4:14 PM

i wonder is it because of this part

Depends: python:any (< 2.8)

Depends: python:any (>= 2.7.5-5~)

since Depends: python:any (>= 2.7.5-5~) does not exist on stretch. Only version there is 2.7.13-2. https://packages.debian.org/stretch/python

and also there's

salt-minion : Depends: python but it is not going to be installed

Depends: python:any (>= 2.6~)

which wants python 2.6 or am i wrong and thats saying it wants python 2.6 or higher?

@andrewbogott I found this https://github.com/saltstack/salt/pull/38927

try sudo apt-get install --reinstall python https://askubuntu.com/questions/718471/error-depends-pythonany-unmet-dependencies-after-installing-python-2-7-5

also why not install the 2016 version. The 2014 one may likely break. https://packages.debian.org/stretch/salt-common

Andrew added a comment.May 5 2017, 4:27 PM

This seems to ultimately come down to conflicts incurred by libssl1.1's dep list

That's for jessie->stretch updates, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844706

We could either

  • use the salt version shipped in stretch on stretch installations (this needs to be supported in some way, since it's impossible to update all minions in a salt environment at once)
  • add an epoch (2:) to our salt packages when rebuilt for stretch

Salt only has a limited remaining life time in our environment, but until debdeploy is migrated to cumin we need an interim solution.

faidon added a subscriber: faidon.May 8 2017, 1:15 PM

Why are you trying to install the jessie version to stretch boxes? In the test box that we've had in prod, the stretch version of salt (as shipped by Debian) works fine with our jessie master. There were some puppet changes required but I did these months ago (cde1a1508c55f93baa79fe1d209d87c5988a6d99, 2b58b1b92f114f1471f80742ef4626c164376d5f).

Andrew closed this task as Invalid.May 8 2017, 1:47 PM

There was some discussion on IRC about this, during which we were briefly in agreement that we should be running the same minion on all hosts. That's clearly not going to happen so I've moved on to (unrelated) issues with getting the new minion to work on Labs. Closing this one.

Why are you trying to install the jessie version to stretch boxes? In the test box that we've had in prod, the stretch version of salt (as shipped by Debian) works fine with our jessie master. There were some puppet changes required but I did these months ago (cde1a1508c55f93baa79fe1d209d87c5988a6d99, 2b58b1b92f114f1471f80742ef4626c164376d5f).

To avoid having 2 (possibly wildly) different versions of salt in our infrastructure is a valid reason IMHO. stretch ships with 2016.11.1+ds-1 and we currently ship and use 2014.7.5+ds-1+wm2[1], so it seemed like a good idea to avoid incompatibilities. And of course it backfired majestically.

Anyway, given our will to sunset salt (soon ?), maybe it's fine to have both versions and whenever we discover some sort of incompatibility, we just ignore it ?

[1] Our local patches seem to be the debian ones according to https://phabricator.wikimedia.org/diffusion/ODSL/browse/master/ which is good.

faidon added a comment.May 8 2017, 7:08 PM

We should stop relying on (ancient versions of) SaltStack altogether, for security reasons among other things. I personally prefer the risk of wildly different salt versions compared to wildly outdated salt versions eveywhere, but I understand it's a choice between two very bad options :)

I filed T164780 for the broader issue of ditching salt entirely. I just hope this won't take long enough for a Salt upgrade to become a necessity.

The debdeploy salt minion is quite self-contained, I wouldn't expect any problems with varying salt versions for debdeploy.