action #70909: salt CI jobs fail due to (now) missing python3 package - openQA Infrastructure - openSUSE Project Management Tool

Actions

Copy link

action #70909

closed

salt CI jobs fail due to (now) missing python3 package

Added by nicksinger over 3 years ago. Updated over 3 years ago.

Status:

Resolved

Priority:

Urgent

Assignee:

okurz

Category:

Target version:

openQA Project - Ready

Start date:

2020-09-03

Due date:

% Done:

Estimated time:

Description

From https://gitlab.suse.de/openqa/salt-states-openqa/-/jobs/242263:

----------
          ID: openqa-trigger-from-ibs-plugin
    Function: pkg.installed
      Result: False
     Comment: An error was encountered while installing package(s): Zypper command failure: Package 'python3' not found.
     Started: 12:51:31.222261
    Duration: 579.521 ms
     Changes:   
----------
[…]
----------
          ID: openqa-trigger-from-ibs
    Function: pkg.installed
      Result: False
     Comment: An error was encountered while installing package(s): Zypper command failure: Package 'python3' not found.
     Started: 12:51:27.233150
    Duration: 2061.742 ms
     Changes:   
----------

From discussion in RC:

okurz: Nick Singer the image is registry.opensuse.org/home/okurz/container/containers/tumbleweed:salt-minion-git-core . I tried it out with podman run --rm -it registry.opensuse.org/home/okurz/container/containers/tumbleweed:salt-minion-git-core and I can confirm that there is no package "python3". python3 is pre-installed so that should not be a problem. And the problem was likely introduced because Tumbleweed recently renamed the package "python3" to "python38".
okurz: I will ask in factory IRC how one is supposed to handle this.

Ideas how to fix it:

if python2 is deprecated now and python now always points to the most recent python3 release we can just replace python3 with python
use python38 as package name and bump it for every minor version upgrade

Actions

Copy link

Updated by okurz over 3 years ago

Status changed from Feedback to In Progress
Assignee set to okurz
Priority changed from Normal to Urgent
Target version set to Ready

if python2 is deprecated now and python now always points to the most recent python3 release we can just replace python3 with python

The package python still exists, see https://software.opensuse.org/package/python?search_term=%22python%22 , and it points to python2.7 so we can not easily use that. http://dominique.leuenberger.net/blog/2020/07/opensuse-tumbleweed-review-of-the-week-2020-31/ describes that python3 is renamed to python38 to allow multiple, parallel installations of python in different versions. That makes sense but I do not understand how I would be able to setup proper dependencies then in salt or something like a zypper command line that is more easy to maintain than just "hardcoding" python38 which seems wrong to me but I do not have a better idea. Problem is that we do not have python38 in Leap. We could delay the problem by using the leap container images as well but that introduces other caveats.

$ podman run --rm -it registry.opensuse.org/opensuse/tumbleweed sh -c 'zypper -n in python3'
…
'python3' not found in package names. Trying capabilities.
Resolving package dependencies...

The following 10 NEW packages are going to be installed:
  libcrypt1 libexpat1 libnsl2 libpython3_8-1_0 libtirpc-netconfig libtirpc3 libuuid1 python-rpm-macros python38 python38-base

works. Maybe there is something special about the containers I use.

$ podman run --rm -it registry.opensuse.org/home/okurz/container/containers/tumbleweed:salt-minion-git-core sh -c 'zypper -n in python3'
…
Reading installed packages...
'python3' not found in package names. Trying capabilities.
'python38' providing 'python3' is already installed.
Resolving package dependencies...

Nothing to do.

ok, so the difference is only that the package is already installed. Everything regarding zypper seems to be in order. Maybe in salt we do not fallback to "capabilities".

EDIT: salt calls zypper --non-interactive --no-refresh install --auto-agree-with-licenses --name python3 where the parameter --name is the problematic one. If we could ask salt to not do that then this would work.

Actions

Copy link

Updated by nicksinger over 3 years ago

Assignee deleted (~~okurz~~)
Priority changed from Urgent to Normal
Target version deleted (~~Ready~~)

okurz wrote:

ok, so the difference is only that the package is already installed. Everything regarding zypper seems to be in order. Maybe in salt we do not fallback to "capabilities".

I think your guess is not that wrong according to the docs at https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.zypperpkg.html#salt.modules.zypperpkg.install :

resolve_capabilities:
    If this option is set to True zypper will take capabilities into account. In this case names which are just provided by a package will get installed. Default is False.

Actions

Copy link