Issues updating packages that use 'latest' versioning

[jlrcontegix]

When attempting to install the latest version of Chrome, for example, the installer is not being executed and the existing version remains. Perhaps I am misinterpreting expected behavior, and assume for packages that use the 'latest' versioning scheme, the installer will be executed each time.

With 3005.1 this does not seem to be the case:

Current version of Chrome installed

# salt 'minion' pkg.version chrome
minion:
    107.0.5304.106

Latest version available at the time of this writing is 107.0.5304.107.

Attempting to install the package results in no output and the installer is not ran:

# salt 'minion' pkg.install chrome
minion:

DEBUG output from the minion:

[DEBUG   ] The functions from module 'pkg' are being loaded by dir() on the loaded module
[DEBUG   ] LazyLoaded pkg.version
[DEBUG   ] Using existing pkg metadata db for saltenv 'base' (age is 2:04:54.471155)
[DEBUG   ] The functions from module 'aggregation' are being loaded from the provided __all__ attribute
[DEBUG   ] The functions from module 'reg' are being loaded by dir() on the loaded module
[DEBUG   ] LazyLoaded reg.list_keys
[INFO    ] Returning information for job: 20221110202347930507
[DEBUG   ] SaltEvent PUB socket URI: 4510
[DEBUG   ] SaltEvent PULL socket URI: 4511
[DEBUG   ] Sending event: tag = __master_req_channel_payload; data = {'cmd': '_return', 'id': 'minion', 'success': True, 'return': '107.0.5304.106', 'retcode': 0, 'jid': '
20221110202347930507', 'fun': 'pkg.version', 'fun_args': ['chrome'], '_stamp': '2022-11-10T20:23:53.815176'}
[DEBUG   ] Closing IPCMessageClient instance
[DEBUG   ] Minion of 'master' is handling event tag '__master_req_channel_payload'
[DEBUG   ] minion return: {'success': True, 'return': '107.0.5304.106', 'retcode': 0, 'jid': '20221110202347930507', 'fun': 'pkg.version', 'fun_args': ['chrome']}
[DEBUG   ] Minion return retry timer set to 7 seconds (randomized)
[DEBUG   ] Subprocess ProcessPayload(jid=20221110202347930507) cleaned up

[darkpixel]

This should be fixed in the latest version of salt

[jrehmer]

We still see this on 3006.6:

minion1:
    ----------
minion2:
    ----------
minion3:
    ----------

When using 'version=latest' in the command it updates:

minion1:
    ----------
    chrome:
        ----------
        new:
            122.0.6261.58
        old:
            121.0.6167.185
minion2:
    ----------
    chrome:
        ----------
        new:
            122.0.6261.58
        old:
            121.0.6167.185
minion3:
    ----------
    chrome:
        ----------
        new:
            122.0.6261.58
        old:
            121.0.6167.185

[darkpixel]

Sorry--I misread things.
If you use version=latest it will check the currently installed chrome version and install only if there is a newer chrome version specified in the sls file. If the current version is 122.0.6261.58 and 122.0.6261.58 is already installed, it won't execute the installer because there's nothing to update.

I've gone round and round with the version=latest stuff and "unversioned" installers like Chrome.

Now I just manually update my sls file every few days to specifically list the version numbers:

# Versions: https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions
#
{% set versions = [
    '122.0.6261.57',
    '121.0.6167.185',
    '121.0.6167.161',
    '121.0.6167.160',
    '121.0.6167.140',
    '121.0.6167.139',
] %}


chrome:
  {% for version in versions %}
  '{{ version }}':
    full_name: 'Google Chrome'
    installer: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise64.msi?v={{ version }}'
    uninstaller: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise64.msi?v={{ version }}'
    install_flags: '/qn /norestart'
    uninstall_flags: '/qn /norestart'
    msiexec: True
    locale: en_US
    reboot: False
  {% endfor %}

In my opinion it's stupid to have an unversioned installer, and it's even worse to use the latest tag and just assume Chrome will keep itself up-to-date.

Explicitly declaring a version number in the file allows the package manager to know that it's out of date.

One way of keeping it up to date automatically might be something like this:

# Versions: https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions
#
{% set data = salt['http.get']('https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions')['body']|load_json %}
{% set versions = [] %}
{% for v in data['versions'] -%}
{{ versions.append(v['version'])|default('', True) }}
{%- endfor %}

chrome:
  {% for version in versions|unique %}
  '{{ version }}':
    full_name: 'Google Chrome'
    installer: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise64.msi?v={{ version }}'
    uninstaller: 'https://dl.google.com/edgedl/chrome/install/GoogleChromeStandaloneEnterprise64.msi?v={{ version }}'
    install_flags: '/qn /norestart'
    uninstall_flags: '/qn /norestart'
    msiexec: True
    locale: en_US
    reboot: False
  {% endfor %}

You can never downgrade because the MSI will automatically install the latest version, but at least version numbers are listed to Salt knows when the installed version is out of date.

[darkpixel]

I should also add that not even Google appears to know the latest version from time to time.

https://versionhistory.googleapis.com/v1/chrome/platforms/win/channels/stable/versions currently lists 122.0.6261.57 as the latest version, but when installing the MSI it reports 122.0.6261.58 (.58 instead of .57) as the installed version.

[jrehmer]

Thanks for the explanations and examples. For our use case it is a small number of Windows machines to deal with, so running the command with 'version=latest' certainly isn't the end of the world, it just struck me as odd needing to do it, but based on your explanation - I get it.

If we had stricter versioning requirements or a larger fleet to manage we'd probably roll our own state definitions similar to what you're doing. When initially reading the documentation and seeing the behavior, it seemed incorrect, but not something I personally find inconvenient. More than once I've reported behavior I didn't understand and either found a bug or got to learn something new about Salt behavior based on responses - of the few communities I deal with here I've learned the most from Saltstack developers and users. :)