Salt: pkgrepo not correctly recognize architecture for apt in test=true

Created on 4 Oct 2018  路  6Comments  路  Source: saltstack/salt

Description of Issue/Question

pkgrepo.managed is not correctly recognizing the architecture for apt based systems when running with test=true. with below scenario test=true always return a change even the repository is correctly setup.

it does not work with the following variations:

  • having [arch=amd64] in the name attribute of the pkgrepo.managed state
  • having architecture: amd64 as attribute of the pkgrepo.managed state

Setup

sls

salt_minion_repo:
  pkgrepo.managed:
    - name: deb [arch=amd64] http://repo.saltstack.com/apt/ubuntu/18.04/amd64/latest bionic main
    - file: /etc/apt/sources.list.d/saltstack.list
    - key_url: salt://{{ slspath }}/files/SALTSTACK-GPG-KEY.pub

Steps to Reproduce Issue

  1. create file /etc/apt/sources.list.d/saltstack.list on salt minion containing the repository with [arch=amd64]
  2. run highstate against the minion with test=true => should show a change (NOT OK)
  3. run highstate against the minion with test=false => not showing a change (OK)

Versions Report

Salt Version:
           Salt: 2018.3.2

Dependency Versions:
           cffi: 1.11.5
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 1.0.7
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: 2.18
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.15rc1 (default, Apr 15 2018, 21:51:34)
   python-gnupg: 0.4.1
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: Ubuntu 18.04 bionic
         locale: UTF-8
        machine: x86_64
        release: 4.15.0-36-generic
         system: Linux
        version: Ubuntu 18.04 bionic
Bug Core P3 fixed-pending-your-verification severity-low team-core

Most helpful comment

There exist two problems while comparing the architecture settings of the repo:

  1. The options _architectures_ and _comps_ are strings and not unicode after read in from current sources file (https://github.com/saltstack/salt/blob/develop/salt/states/pkgrepo.py#L396) and due to this the comparison fails between unicode and string (https://github.com/saltstack/salt/blob/develop/salt/states/pkgrepo.py#L469).
  2. If the 1st problem has been solved the next comparison fails because of the missing architecture option in the _sanitizedsplit_ variable (https://github.com/saltstack/salt/blob/develop/salt/states/pkgrepo.py#L447).

I was unable to solve this in a nice way, but maybe it drives you to the right direction.

All 6 comments

seems there were other issues reported that had problems with test=true for pkgrepo.managed:

unfortunately both of those issues were closed and the problem still seems to persist.

Yup, looks like this just needs to be able to handle the architecture to see if there needs to be a change.

@terminalmage do you have time to look at this since you fixed those other two pretty quickly?

Thanks,
Daniel

There exist two problems while comparing the architecture settings of the repo:

  1. The options _architectures_ and _comps_ are strings and not unicode after read in from current sources file (https://github.com/saltstack/salt/blob/develop/salt/states/pkgrepo.py#L396) and due to this the comparison fails between unicode and string (https://github.com/saltstack/salt/blob/develop/salt/states/pkgrepo.py#L469).
  2. If the 1st problem has been solved the next comparison fails because of the missing architecture option in the _sanitizedsplit_ variable (https://github.com/saltstack/salt/blob/develop/salt/states/pkgrepo.py#L447).

I was unable to solve this in a nice way, but maybe it drives you to the right direction.

Closing this out, if the problem persists please comment & we'll re-open the issue or feel free to open a new issue.

@garethgreenaway i would like to keep this open as the corresponding PR #50921 has not yet been merged.

Was this page helpful?
0 / 5 - 0 ratings