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

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.

[github-abcde]

I can see where you are going with this. The “major release” versions of Ubuntu consist of (at least according to https://en.wikipedia.org/wiki/Ubuntu_version_history) the first two sets of digits. So for Ubuntu, 16.04 would be the osmajorrelease, and the full osrelease would be 16.04.6.

[boltronics]

Yep, I did see some Centos-specific tests in there. You can see in my above references to _linux_distribution(): that it is named with the underscore (a last minute change to the PR that addressed that) - indicating that all of my work above was done after the fix for that other issue was already merged, so is not affected by the changes.