Salt: Debian 10 (Buster) Repo : Error 404 Not Found

[d4v1dm013]

Description of Issue

I have installed last week salt-minion in a Debian Buster fresh install successfully, but today when i want to upgrade via apt-get update, The debian 10 (buster) repository of saltstack return a 404 Not Found Error :
http://repo.saltstack.com/py3/debian/10/amd64/latest

No problem for debian 9 and older.

Setup

OS : 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux

Steps to Reproduce Issue

apt-get update
Ign :4 http://repo.saltstack.com/py3/debian/10/amd64/latest buster InRelease
Err :5 http://repo.saltstack.com/py3/debian/10/amd64/latest buster Release
404 Not Found [IP : xxx]

Versions Report

Don't needed here

Do you have change url of the repository or something like that ?

Thanks.

[c-wicklein]

I noticed a similar problem today affecting CentOS 8, so it's probably not a Debian-specific issue.

Affected users will find that pkg.installed is unable to install packages on RHEL/CentOS systems.

I had installed Salt with sudo dnf install https://repo.saltstack.com/py3/redhat/salt-py3-repo-latest.el8.noarch.rpm (2019.2.1.) Things were fine until today when a sls tried using pkg.installed but failed on sync'ing the Salt repo. I checked the URL in /etc/yum.repos.d/salt-py3-latest.repo and found it was no longer vaild. I fixed it with the change below. It feels like the repo was updated to introduce a new version of salt and to roll 2019.2.1 from latest to archive, except there isn't a new version of Salt...

~/salt(master*) » diff -Nur /etc/yum.repos.d/salt-py3-latest.repo.bak /etc/yum.repos.d/salt-py3-latest.repo                                                                                              me@laptop
--- /etc/yum.repos.d/salt-py3-latest.repo.bak   2019-05-15 10:52:18.000000000 -0500
+++ /etc/yum.repos.d/salt-py3-latest.repo   2019-10-10 20:32:12.122875825 -0500
@@ -1,6 +1,6 @@
 [salt-py3-latest]
 name=SaltStack Latest Release Channel Python 3 for RHEL/Centos $releasever
-baseurl=https://repo.saltstack.com/py3/redhat/8/$basearch/latest
+baseurl=https://repo.saltstack.com/py3/redhat/8/$basearch/archive/2019.2.1
 failovermethod=priority
 enabled=1
 gpgcheck=1

[teran-mckinney]

Absolutely ridiculous.

You can find it here:
http://repo.saltstack.com/py3/debian/10/amd64/archive/2019.2.1/

There's an explanation here: http://repo.saltstack.com/

2019.2.1 was working fine for me. This just broke my automation.

[d4v1dm013]

Ok understand.

I think it would be good to remove/update the link temporaly from the documentation to avoid misunderstanding.

[teran-mckinney]

I meant that Saltstack doing this is ridiculous, not your ticket. Sorry if that was confusing.

Can you reopen this? Latest was supposed to point to 2019.2.0.

The latest and 2019.2 repo links point to the version 2019.2.0 until 2019.2.2 is released.

It is definitely a bug.

[dmurphy18]

@teran-mckinney There is no 2019.2.0 for Salt on Debian 10, support was only introduced in 2019.2.1, similarly Redhat 8 and Amazon Linux 2.

As in the WARNING message:
_If you are on an operating system whose support was introduced in version 2019.2.1, please use the 2019.2.1 release available in the archive. For those newly supported operating systems, please be aware that there will be no latest or 2019.2 repo links._

The link for Debian 10 for Salt 2019.2.1 is http://repo.saltstack.com/py3/debian/10/amd64/archive/2019.2.1

as shown in the _Pin to Minor Release_

Latest and 2019.2 links will be restored once Salt 2019.2.2 is released which should be next week, unless no last minute discoveries are made in testing.

[teran-mckinney]

Got it, thank you. Still, don't know why it was done this way. 2019.2.1 was completely fine for me. I didn't see any security vulnerabilities listed or some huge reason why I shouldn't use it, if not impacted by those listed bugs.

[dmurphy18]

@teran-mckinney It had issues with Event Returner (Py3), IPv6 support, some Jinja template issues and a pip issue. This generated a large number of support calls, so decisions got made, which are now having a root cause analysis done on to ensure we don't repeat previous missteps.

Sorry about the interruption, _to err is human_, hence the attempts to add more automation but still need to address human decisions about pushing the correct buttons.

[c-wicklein]

I could see pulling the release for systems where 2019.2 is available to prevent additional users from installing it, but for systems which were first supported by 2019.2.1, pulling the release without a fall back version and hosing the repo path is pretty disruptive.

[c-wicklein]

Which missteps are you reviewing? Shipping 2019.2.1 or breaking RHEL 8 by pulling 2019.2.1 across all platforms?