Hi everyone, this is Dan from the Factory 2.0 team.
Today I'd like to talk about an API change we're planning to make in Greenwave.
Just bear in mind this isn't implemented yet, and it's not set in stone.
But I'm going to describe our current thinking and our reasons for making the change.
Just to refresh your memory, Greenwave is a service we built
in the Factory 2.0 team.
Its job is to take test results from ResultsDB
and waivers from WaiverDB, and then use those
to decide whether a build is good enough to pass certain gating points.
Today in Fedora, Bodhi already consults Greenwave
when it's deciding whether an update is ready to be pushed.
And we expect to see more tools and more gating points using Greenwave in future as well.
When you ask Greenwave for a decision, the most important thing you need to tell it is
what artefact you want a decision about.
That could be a particular package build in Koji,
or it could be a compose, or something else.
In the Greenwave API we call that parameter the "subject".
And you can see it here in the API docs for the current version of Greenwave.
Right now, the "subject" parameter is a list of dicts.
Each item in the list is supposed to match the key-values
that are stored with the test results in ResultsDB.
In the original design, Greenwave intentionally doesn't know anything about what these subjects actually are.
It just looks up results in ResultsDB by passing along the key-values from the subject parameter.
We wanted to keep it simple
... and it is simple, when you just have one package build that you want a decision about.
But we found that things started to get messier when you start talking about a Bodhi update
which can have multiple builds attached to it.
I'm going to jump over to the Greenwave issue where we're discussing this change.
I've got an example here of a decision that Bodhi has requested.
You can see that Bodhi has to fill in the "subject" parameter
with the update itself,
and also each of the builds that are in the update.
And each build is identified in two different ways.
That's because we have different kinds of tests which are reporting their results into ResultsDB
in different ways, depending on what exactly they tested.
But we want to gate the Bodhi update on a combination of all of these different test results.
With the current design that means Bodhi, as the consuming tool,
has to understand all this complexity about which test results are applicable to an update.
And it makes the policy more difficult to write as well.
But there's an even bigger problem.
We want Greenwave to be message-driven.
So when it sees a new result or a new waiver has appeared,
it should figure out if any decisions have changed and then publish a message saying so.
We want Bodhi to listen for those messages, so it knows straight away when an update is
ready to be pushed. It doesn't have to keep polling Greenwave over and over.
The problem we have is, right now Greenwave doesn't know what all the possible subjects are
that it could be making a decision about.
If it sees a test result come in for some package build,
it doesn't know if that also affects the decision for some update in Bodhi.
Our solution is that we're going to teach Greenwave
that stuff.
It will understand that a Bodhi update has one or more Koji builds.
And it will know how to piece together all the different test results, in order to make a decision about an update.
Greenwave will understand all the different subjects that you can ask it about.
To make that clear for consumers, we're going to introduce v2 of the API.
The "subject" parameter will be replaced with two new parameters: "subject_type",
and "subject_identifier".
For now, we'll define three subject types that Greenwave knows how to handle:
Koji builds, Bodhi updates, and composes.
We expect to add more in future as well.
You can see here, this is the decision that Bodhi would request instead, using the new API.
And Greenwave will preemptively publish these decisions on the message bus as well.
We think this change is going to help us simplify things, and fix a lot of problems we've encountered.
But if you have any thoughts about the API change, send us an email
or write a comment on the Greenwave issue.
Thanks for listening.