Hi everybody, this is Dan from the Factory 2.0 team.

Today I've got a quick demo for you showing the new Greenwave API changes for 
"subject type".

We were previously calling this work the Greenwave v2 API but we were actually 
able to make the changes backwards compatible. We've introduced new request 
parameters and new keys in the response objects, but we've also preserved all 
the old ones so it's not a totally separate version 2 of the API.

You might remember in a previous video I talked about why we wanted to make 
these API changes. Well to give you a quick reminder...

Test results in ResultsDB have an arbitrary set of key-values attached to them. 
So for example, you can see this test result has "type" of "brew-build", and it 
has an NVR in the "item" key. That's one convention, which came from the 
Taskotron system in Fedora. But other systems are representing their results in 
different ways. Greenwave needs to use these test results in order to make its 
decisions.

So in the original design of Greenwave we wanted to keep it generic. It wasn't 
aware of these different conventions for test results. The caller would pass in 
an arbitrary set of key-values when they ask Greenwave for a decision, and then 
Greenwave would look up the test results using the same set of key-values that 
it was given. That was the "subject" parameter, which Greenwave has always had, 
and that's what we've deprecated now.

You can see it in action here, if I send a POST request to Greenwave... I'm 
going to request a decision for the "rhel-8" production version... the 
"osci_compose_gate" decision context, and subject— this is the parameter that 
we've now deprecated— it would look like this. I would say... "type": 
"brew-build", and the "item" would be my NVR. and that matches up with the 
key-values that exist on the result, like we saw before. I'm just going to make 
up a non-existent NVR for right now.

So you can see in the request body here, we've got "subject" parameter, which 
is this list. This doesn't seem too unreasonable, but if you remember when we 
are talking about Bodhi making a request for a decision from Greenwave, it 
actually needs to fill in a whole list of different sets of key-values for not 
only the update itself, but then for all the builds that were in the update, 
and all the differents ways that we record results for different builds. So 
that's really the biggest downside with this approach, it's that all of 
Greenwave's callers have to understand all the different ways that we store 
results in ResultsDB. It adds unnecessary complexity for the other services 
when they want to make their requests, and also if they want to listen for 
decisions from Greenwave on the message bus.

So instead of arbitrary key-values, we've now introduced two new parameters: 
"subject_type" and "subject_identifier". If I repeat that same request as 
before, I'm going to replace the "subject" parameter with the two new ones. 
"subject_type" here is going to be "koji_build", and "subject_identifier" is 
the NVR. And if you were reading the output before, you would have seen that 
we've actually got, in the response from Greenwave, we've actually got the new 
keys appearing, the "subject_identifier" and the "subject_type". But we also 
have "item" which is actually the previous... This "item" nested inside "item" 
was the slightly bizarre API that we had before.

The key difference is that the subject type has to be one of the subject types 
that Greenwave understands. So we've defined three subject types so far, based 
on how Greenwave is being used in Fedora. They're written up in the Greenwave 
API docs, which you can see here. For each of the subject types, the docs say 
what the format of the identifier is.

And the other major difference is that Greenwave can now have extra logic 
associated with each subject type. So when you ask Greenwave for a decision 
about a Bodhi update, it now knows that it also needs to check the policies for 
each build in the update, and it will enforce those too. So that makes life 
much simpler for the caller. It does mean we now have more logic living in 
Greenwave, but otherwise every caller and message consumer had to have the same 
logic and we think it's better to consolidate it here in one place inside 
Greenwave.

And lastly, just to add a bit of pizzazz to the demo, I'd like to show the same 
thing in action with the message-driven workflow.

So what I have here is a Jenkins job, it's a fake Jenkins job that knows how to 
send messages on the stage message bus pretending to be a test result. So I'm 
going to send a new result which matches the policy that I was asking for 
a decision a second ago, with the same fake NVR. And we should see, if we 
refresh the page here, this is the Datagrepper stage, we've got a new result 
appeared just now. Let's take a look at what's in there. We can see that it 
came from my fake Jenkins job, and that it's been recorded with "type" of 
"brew-build", and the "item" is the fake NVR that I was using before.

And if we jump over here and request the same decision again, we'll see that 
Greenwave now considers all the requirements to be satisfied because that test 
result exists and it's passing. So that's great.

But the message driven part of it is actually here. Right now I'm going to jump 
over to the OpenShift console, and we're looking at the logs for the 
resultsdb-consumer pod in Greenwave. And if I scroll up a little bit, we'll see 
that Greenwave found the new result which appeared in ResultsDB for the fake 
NVR. And it's decided that now the policy's satisfied, so you can see... It's 
a bit hard to read because we're looking at a log message, but we can see that 
all results... all required tests passed.

And... You can see that we have the "subject" key here in the message. This is 
the deprecated one, but it's still present for compatibility. But you can see 
we also have the new parameter "subject_type" with the value of "koji_build", 
and the new "subject_identifier". So this matches the same parameters that are 
in the request body when you make a request. We've got the same in the messages 
that Greenwave is producing, and it's backwards compatible in the same way.

And of course the message actually failed to send, because we have 
a misconfiguration in our stage environment so I hope you'll forgive me for 
that. :-)

All right, thanks very much for listening everyone. See you next time.