There are various status pages that are relevant for developers to track, e.g. https://status.testing-farm.io/ and https://status.packit.dev/, and it would be helpful to have a more centralized location to look for related statuses. This could be done as either: - Embed the contents of those pages as-is - Create indivudal checks that check the contents of the pages, e.g. Fedora CI match Operational
Fedora CI
Operational
In both of these cases, these are static pages so maybe some html parsing wizardry can incorporate the contents there.
https://status.fedoraproject.org/ is a static page that is build from this GitHub repository https://github.com/fedora-infra/statusfpo. It shouldn't be issue to add links to other status pages, but as this is a static page I'm not sure if we can embed them directly.
If you want you can look at the repository by yourself and work on this.
Metadata Update from @zlopez: - Issue priority set to: Waiting on Assignee (was: Needs Review) - Issue tagged with: high-gain, low-trouble
Being a static site should not be a problem, I believe this could be done via <iframe> or such for the pure embeding approach. The dynamic check would probably require some javascript. I do not know html/javascript myself so wouldn't know how to approach it other than monkeying around with online tutorials.
<iframe>
Lets hang on a bit here. ;)
The goal of www.fedorastatus.org is to be a simple end user / contributor status space, where we manually update when a issue is known/being investigated with simple descriptions.
ie, the goal is to say "There is a problem with dnf updates..." or "The buildsystem isn't processing builds due to heavy scraper activity" or the like and to deliberately avoid things like "rabbitmq cluster is having problems" where people wouldn't have any idea what the impact of that would be. Or "proxy26 is down" which doesn't convey whats going on. Or 'bodhi is down' (where lots of people wouldn't realize what 'bodhi' is).
How are these other status pages updated?
I realize contributors would be interested in this information and could perhaps parse it, but adding it to the main status area could confuse users. For example the testing farm status has a bunch of RHEL related things listed right now (and has since last week) Will users know what 'testing farm' and 'packit' are?
Perhaps it would be better to just let you all add status in those cases where the problem is large/widespread/important and/or just provide links to the other status pages with a 'contributor ci status' or something?
Or I suppose we could split www.fedorastatus.org to be just end user and make a new fedoracontributorstatus.org that was more targeted at all contributor services? That seems like a lot of work though.
Agreed, and I do not want to disturb that, i.e. a few minimum requirements are: - infra status updates workflow and display stays the same - When an issue occurs in testing-farm or packit, it would not require neither a manual or automated update to the fedora infra status page - Updates to the external statuses would not trigger an RSS update from infra page (maybe if someone knows more about how to make a combined RSS feed that would be interesting), or similar to other notification methods - The embeded content should be clear that it is external
My thinking is to have an embeded page or preview of the contents in the other pages. Definitely some javascript magic can be made to fetch it dynamically when the user loads the page. As for the location of the script it would be outside of the templated content, e.g. just above here.
That's an interesting point to consider. Definitely not all statuses there are relevant. One hint could be that the content looks distinct that not all of the outages there are affecting everyone. Another option would be to have a small javascript scriplet that would fetch only the relevant outages, e.g. Fedora-CI outage on the testing-farm status.
The main reason for having a central place to at least aggregate the statuses is that we often have some wide-spread inter-connected issues, e.g. high back-log in s390x builders affecting FedoraCI scratch-build or missing Fedora compose affecting packit upstream tests. That is for the user side not having to guess which outage where is causing issues, but it can be an issue even for the reporter, e.g. with the upcoming Packit Fedora-CI being run on Fedora infra, an issue can occur from all 3 places fedora-infra, packit-service or testing-farm and it would be fun figuring out on which page to post it.
I want to avoid burdening the status page, so preferably we should check how we can do automatically on the browser side.
Yeah, a lot of work and would probably aggravate the main issue that this is trying to solve, having a simple place to check if there is something happening somewhere.
Would it make more sense to just include links to these places? Then interested folks could go to them directly?
From my side I have no problem adding general outages/etc from other related teams directly but that wouldn't meet your listed requirements.
This issue has been migrated to Fedora Forge: https://forge.fedoraproject.org/infra/tickets/issues/12759
Please continue any further discussion there.
Metadata Update from @ryanlerch: - Issue close_status updated to: Migrated to Fedora Forge - Issue status updated to: Closed (was: Open)