All issues, including operational, can be opened on the Warehouse repository. The talk of having no SLA is to set expectations that we don’t have an on call rotation or people getting paged for downtime. Opening an issue means we’ll (hopefully) see it and take a look, but if some business process relies on having high uptime on PyPI, you’re better off taking ownership of that up time yourself.
That isn’t to mean we don’t care about it, but just that we don’t make any promises.
404’s don’t sound like something that would show up in a status dashboard at this time, so that makes sense. Maybe we could improve our metrics such that it would, but currently it would not.
I don’t understand what the actual issue is happening here. The launchpad that is being linked from that page is 5 years old, and suggests random networking issues, but you’re saying it’s 404 errors? The Kibana URL suggests the problem might lie with oslo.log, but I just checked all 15 pages of CDN nodes, and they all have the same 200 response cached for https://pypi.org/simple/oslo-log/.
If there’s some issue here, I suggest opening an issue with reproduction steps that don’t involve going through openstack’s infra if at all possible.
As we said, we can’t afford or manage to operate a public endpoint that isn’t behind a CDN, it would scale our operations significantly. The handful of endpoints we have that can somewhat bypass the CDN are regularly problems for us, and they’re not nearly as popular as the repository API.