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.