On Wed, 13 Jan 2021 at 18:53, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
Hi folks!
Before the RH holiday shutdown, I started a new project designed to
address a long-standing pain point in Fedora: we don't really have a
good source of truth for release cycle information. I'm thinking of
situations where something:
* Needs to know what the "current stable" Fedora release(s) are
* Needs to know if Fedora X is Branched
* Needs to know whether Fedora X Beta happened yet
* Needs to know whether Fedora X is frozen
...etc etc etc. Some of this information is available...sort of...from
various different systems, with various awkward caveats that I won't
dive into unless someone asks. But there isn't really a single source
of truth for it, and some of it just isn't really available in any
easily machine-consumable way.
So I wrote releasestream:
https://pagure.io/fedora-qa/releasestream
releasestream is intended to be a system that will let us do this. It
is a very very simple webapp with three capabilities:
* It can read a simple record ("stream") of "release events" for a
"release" and produce several static JSON representations of the
information
* It can write an entry to one of these streams in response to a
properly-formatted POST request
* It can publish a message when a new entry is received
that is all it does. The "releases" and "events" are entirely
arbitrary; a "release" can be any string, and so can the "state" for a
given "event". An "event" is defined as a state being either reached or
left; any number of events for the same state can be present for a
release.
The JSON outputs are basically "states by release" and "releases by
state", as you might want either depending on what you're doing. You
can conveniently look up "what releases are currently in state X?" or
"what states is release X currently in?".
This all works right now; the main thing that isn't implemented yet is
any form of authentication. Right now if you can talk to the server you
can submit events. I wanted to check if there is interest in moving
forward with this, and discuss various options, before working on that.
There is a ticket where I sketched out various possible approaches:
https://pagure.io/fedora-qa/releasestream/issue/2
My idea for using this is basically that we deploy an 'official'
releasestream instance in infra, and then find things that do the
actual work of moving Fedora releases into and out of given "states"
and tack on a bit at the end to tell releasestream about it. So when
e.g. Mohan is putting Fedora 34 into the Beta freeze, we would add a
"submit 'enter freeze' event to releasestream" to that process somehow
- ideally something that has to be run as part of the process anyway
would send the POST, but in a pinch a human could do it too. When
Fedora 34 is being 'released', we tweak that process to include sending
a releasestream event POST. And so on.
The thing I like about this design is that there's a low barrier to
entry, and can easily be adopted piecemeal but still be immediately
useful for some things - as long as the event your code needs to watch
for has been "onboarded", you're good. It also allows for the
implementation details of a state change to change radically - it can
go from being done by a human to being done by system X to being done
by system Y, and all that needs to happen is to ensure the same dead
simple POST request is sent to the same server.
So, what do folks think? Does this seem like a good idea? Should I go
ahead with trying to get it deployed and onboard things to it? Any
comments, ideas, potential problems? Thanks!
I am pretty sure you did :-) but have you looked at adding the missing information to Bodhi ? Now that we have rawhide in Bodhi we should be able to expose most the information needed.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
_______________________________________________
rel-eng mailing list -- rel-eng@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to rel-eng-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/rel-eng@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
