On Wed, 13 Jan 2021 at 18:53, Adam Williamson <adamw...@fedoraproject.org> 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-...@lists.fedoraproject.org > To unsubscribe send an email to rel-eng-le...@lists.fedoraproject.org > 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-...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
