salt: Saltstack repository - status page/public mirror possibility? And causing stucked install states?

Hello,

It would be great to have

• a public status page to easily recognize down/routing/ddos/… issues
• the possibilty for public mirrors like most OSS offers so it’s easy
  • to lower the impact of data transfers for you / make traffic more “localized”
  • switch to (other) mirrors if such failure occurs

Actual (over 3-4 hours yet) the saltstack repository repo.saltstack.com is mainly not available in Germany - different locations tested for the case it’s geoip distributed… so

• fresh setup is not possible
• but also other states which tries to setup packages get stucked for hours… (I killed 1st run av e.g.:

[INFO    ] Executing state pkg.installed for [python-redis]
[DEBUG   ] Could not LazyLoad pkg.normalize_name: 'pkg.normalize_name' is not available.
[DEBUG   ] Could not LazyLoad pkg.check_db: 'pkg.check_db' is not available.
[DEBUG   ] Could not LazyLoad pkg.normalize_name: 'pkg.normalize_name' is not available.
[INFO    ] Executing command ['dpkg', '--get-selections', '*'] in directory '/root'
[INFO    ] Executing command ['systemd-run', '--scope', 'apt-get', '-q', '-y', '-o', 'DPkg::Options::=--force-confold', '-o', 'DPkg::Options::=--force-confdef', 'install', 'python-redis'] in dire[...]

which is very weird…

I was checking the cause of this stucked states (running salt-call 2017.7.2 (Nitrogen)) which keeps apt locked (latest Debian Stretch Cloud image).

As state the installs stopped working; it seems after the package install routine itself but apt/history log has no finished entry written. And apt-get is so busy that even a kill -9 $(pidof apt-get) is not cancelling the call which is extremely unknown behavior for such tasks … => Perhaps it comes because of running it as child of systemd-run ? When running the install manually which I tested for comparison / check if there is an apt problem it’s all fine there.