saltstack / saltstack/salt

[BUG] release-related grains returning unexpected values on Ubuntu

Open
#58,010 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Linux severity-medium
Dominant language
Python
Stars
15.7k
Forks
5.6k
Avg merge
2d 44m
Merged PRs (30d)
80

Description

Description
I have two test boxes. One runs Ubuntu Xenial 16.04.6 LTS, and the other is Debian 9 Stretch. Both are running on amd64.

  • For Ubuntu, the major release version is 16.04, and the minor version is 16.04.6.
  • For Debian, the major release version is 9, and the minor version is 9.13.

On Debian the related grains are returned exactly as expected:

    lsb_distrib_codename:
        stretch
    lsb_distrib_description:
        Debian GNU/Linux 9.13 (stretch)
    lsb_distrib_id:
        Debian
    lsb_distrib_os:
        GNU/Linux
    lsb_distrib_release:
        9.13
    oscodename:
        stretch
    osfinger:
        Debian-9
    osfullname:
        Debian
    osmajorrelease:
        9
    osrelease:
        9.13
    osrelease_info:
        - 9
        - 13

On Ubuntu, I would similarly expect:

    lsb_distrib_codename:
        xenial
    lsb_distrib_description:
        Ubuntu 16.04.6 LTS
    lsb_distrib_id:
        Ubuntu
    lsb_distrib_os:
        GNU/Linux
    lsb_distrib_release:
        16.04
    oscodename:
        xenial
    osfinger:
        Ubuntu-16.04
    osfullname:
        Ubuntu
    osmajorrelease:
        16.04
    osrelease:
        16.04.6
    osrelease_info:
        - 16
        - 4
        - 6

Instead we have:

    lsb_distrib_codename:
        xenial
    lsb_distrib_description:
        Ubuntu 16.04.6 LTS
    lsb_distrib_id:
        Ubuntu
    lsb_distrib_release:
        16.04
    oscodename:
        xenial
    osfinger:
        Ubuntu-16.04
    osfullname:
        Ubuntu
    osmajorrelease:
        16
    osrelease:
        16.04
    osrelease_info:
        - 16
        - 4

Setup
No setup required - these are built-in grains.

Steps to Reproduce the behavior
salt 'somehost' grains.items

Expected behavior

  • 16.04 is returned as the full OS version in both osrelease ond osrelease_info. This is incorrect. It should report 16.04.6.
  • 16 is treated as the major OS version in osmajorrelease. It this incorrect as there is no such release, so it's quite meaningless. There is only 16.04 and 16.10 major versions, and in this case it should report 16.04.
  • Also, lsb_distrib_os probably should not be missing.

Versions Report
On a Debian host:

Salt Version:
           Salt: 2019.2.5
 
Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 2.5.3
      docker-py: Not Installed
          gitdb: 2.0.0
      gitpython: 2.1.1
          ioflo: Not Installed
         Jinja2: 2.8
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: 0.24.0
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.8
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 2.7.13 (default, Sep 26 2018, 18:42:22)
   python-gnupg: 0.3.9
         PyYAML: 3.12
          PyZMQ: 16.0.2
           RAET: Not Installed
          smmap: 2.0.1
        timelib: Not Installed
        Tornado: 4.4.3
            ZMQ: 4.2.1
 
System Versions:
           dist: debian 9.13 
         locale: UTF-8
        machine: x86_64
        release: 4.9.0-12-amd64
         system: Linux
        version: debian 9.13 

On a Ubuntu host:

    Salt Version:
               Salt: 2019.2.5
     
    Dependency Versions:
               cffi: Not Installed
           cherrypy: Not Installed
           dateutil: 2.4.2
          docker-py: Not Installed
              gitdb: Not Installed
          gitpython: Not Installed
              ioflo: Not Installed
             Jinja2: 2.8
            libgit2: Not Installed
            libnacl: Not Installed
           M2Crypto: 0.21.1
               Mako: 1.0.3
       msgpack-pure: Not Installed
     msgpack-python: 0.4.6
       mysql-python: Not Installed
          pycparser: Not Installed
           pycrypto: 2.6.1
       pycryptodome: Not Installed
             pygit2: Not Installed
             Python: 2.7.12 (default, Jul 21 2020, 15:19:50)
       python-gnupg: 0.3.8
             PyYAML: 3.11
              PyZMQ: 15.2.0
               RAET: Not Installed
              smmap: Not Installed
            timelib: Not Installed
            Tornado: 4.2.1
                ZMQ: 4.1.4
     
    System Versions:
               dist: Ubuntu 16.04 xenial
             locale: ascii
            machine: x86_64
            release: 4.4.0-1109-aws
             system: Linux
            version: Ubuntu 16.04 xenial

Additional information
The reason why this is annoying is because I want to add official Salt repositories, using grains to populate the URL.
eg. http://repo.saltstack.com/py3/{{ grains['os']|lower }}/{{ grains['osmajorrelease'] }}/{{ grains['osarch'] }}/latest
This should produce URLs like:

  • http://repo.saltstack.com/py3/debian/9/amd64/latest
  • http://repo.saltstack.com/py3/ubuntu/16.04/amd64/latest

But instead I get invalid URLs on Ubuntu hosts, like http://repo.saltstack.com/py3/ubuntu/16/amd64/latest.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue with salt 'somehost' grains.items on Ubuntu 16.04.6 and Debian 9.13, then trace the built-in grain values for osrelease, osmajorrelease, osrelease_info, and lsb_distrib_os. Done means Ubuntu reports 16.04.6, 16.04, and all three release components consistently, with lsb_distrib_os present, without regressing Debian values.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
devops, infrastructure, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.