salt v2016.3.2 changes grains['osfinger'] from 'Ubuntu-14.04' to 'Ubuntu-14'

[muep]

Description of Issue/Question

Salt versions 2016.3.1 and earlier had Ubuntu 14.04 systems report "Ubuntu-14.04" in the osfinger grain. Salt-minion 2016.3.2 on a similar system will have just "Ubuntu-14" in the same grain.

A system administrator may quite often write jinja templates that check for an exact string in that grain. The change in the grain will require a large number of adjustments in the Jinja templates.

Setup

No special setup needed. Just some Ubuntu 14.04 minions and a master to control them. My testing was done with the minion and master being the same system.

Steps to Reproduce Issue

• Install salt-minion 2016.3.2 on a system running Ubuntu 14.04.
• Run salt -G osfinger:Ubuntu-14 grains.item saltversion

Versions Report

Salt Version:
           Salt: 2016.3.2

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
          gitdb: 0.5.4
      gitpython: 0.3.2 RC1
          ioflo: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: 0.9.1
   msgpack-pure: Not Installed
 msgpack-python: 0.4.6
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
         Python: 2.7.6 (default, Jun 22 2015, 17:58:13)
   python-gnupg: Not Installed
         PyYAML: 3.10
          PyZMQ: 14.4.0
           RAET: Not Installed
          smmap: 0.8.2
        timelib: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.5

System Versions:
           dist: Ubuntu 14.04 trusty
        machine: x86_64
        release: 4.4.0-31-generic
         system: Linux
        version: Ubuntu 14.04 trusty

[muep]

To me, it looks like commit 9a6b217 would change content of osfinger on Ubuntu from name-version to name-( osrelease_info[0] ).

[cachedout]

@isbm it looks like this did end up with some unintended consequences.

That said, now that this change has been made I am reluctant to revert this. I don't want to flip-flop between schemes...

[muep]

Based on further examination, the truncated version number in osfinger seems to be present regardless of Ubuntu version.

Keeping it truncated has a number of issues:

• osfinger no longer allows distinguishing between e.g. Ubuntu 17.04 and Ubuntu 17.10
• a mix of salt minion versions[1] will result in inconsistent values in osfinger

[1] latest salt does not seem to be easily available e.g. for i386 or ARM installations of Ubuntu

At least I am initially working around this by overrding the grain in minion configuration, rather than changing all the locations in sls files where the osfinger grain is used. Given that the new behavior seems somewhat hide the exact major release of the OS, I guess some might end up doing that longer-term or just switch to using the other grains that include the full OS release number.

[rstarkey]

I too was bitten by this and I've worked around it but what a PIA to have two different behaviors of a grain based on different versions of salt.

@cachedout, I vote to fix something that's broken. Changing core grain behavior without a deprecation notice is bad form. Fix it and call it a regression in 2016.3.2.

[MTecknology]

After looking over the patch, it seems it was written to reduce redundant (spaghetti) code. It seemed to do an excellent job of that.

I'm tempted to ask why a change like this made it into a point release in the first place because it did not seem to resolve any open bugs in the previous release. ( but I won't )

In the case of Ubuntu, 16.04 is the major release version. As much as we'd love to see them drop the dot and make this silly edge case go away, that's not going to happen. The way this sits currently, 16.04 and 16.10 will be the exact same osfinger.

I would argue that not reverting back to the previous behavior (including keeping it for all future salt releases) would render osfinger almost entirely useless on Ubuntu systems.

(other factors included..) I would strongly recommend reverting to the previous behaviour and wrapping it up into a quick .3 release so that the impact of this bug can be kept as low as possible.

@cachedout If I can do anything to help minimize this issue, you know what network I live on. :)

@Ch3LL @cachedout If we're still blocked on discussion, I'll be happy to include a more in-depth explanation of why this is potentially a very major bug. If we're blocked on more, I'd love to help with that as well.

[isbm]

I'd rather extend what it is now to pass Ubuntu (and it is really easy), instead of returning back all those spaghetti code as per #35221 PR. Also I don't see any unit test case from Ubuntu guys. 😏 Instead of accepting #35221 I would rather do the following:

1. Add a unit test for Ubuntu.
2. Add to the existing code what is missing.

Raspbian anyone? Actually I am on Ubuntu system right now (ironically), so I can came up with a fix for this in a short time. Let's not introduce spaghetti just because something is failing.

[Ch3LL]

@muep would you mind giving the fix in #35227 a try?

[muep]

With the self-contained development setup as instructed in HACKING.rst, it seems to work fine on Ubuntu 14.04. osfinger is set to 'Ubuntu-14.04' again. Tried with these commits from 2016.3 branch:

• c032506 (branch head at time of testing)
• fe5da97 (last from the pull request)

[Ch3LL]

Awesome thanks for trying that out. I will go ahead and close this for now and this will be in the next 2016.3.3 release.

[muep]

Thank you, all, for addressing this. Looking forward to the 2016.3.3 release!