1 00:00:00,293 --> 00:00:03,520 Hi everybody, this is Dan from the Factory 2.0 team. 2 00:00:03,748 --> 00:00:09,647 Today I've got a quick demo for you showing the new Greenwave API changes for "subject type". 3 00:00:09,647 --> 00:00:14,373 We were previously calling this work the Greenwave v2 API 4 00:00:14,373 --> 00:00:17,568 but we were actually able to make the changes backwards compatible. 5 00:00:17,698 --> 00:00:22,815 We've introduced new request parameters and new keys in the response objects, but we've also preserved 6 00:00:22,815 --> 00:00:28,389 all the old ones so it's not a totally separate version 2 of the API. 7 00:00:28,943 --> 00:00:33,480 You might remember in a previous video I talked about why we wanted to make these API changes. 8 00:00:33,480 --> 00:00:35,690 Well to give you a quick reminder... 9 00:00:35,690 --> 00:00:41,720 Test results in ResultsDB have an arbitrary set of key-values attached to them. 10 00:00:41,720 --> 00:00:52,792 So for example, you can see this test result has "type" of "brew-build", and it has an NVR in the "item" key. 11 00:00:53,486 --> 00:00:57,365 That's one convention, which came from the Taskotron system in Fedora. 12 00:00:57,365 --> 00:01:00,918 But other systems are representing their results in different ways. 13 00:01:00,918 --> 00:01:04,731 Greenwave needs to use these test results in order to make its decisions. 14 00:01:04,992 --> 00:01:11,804 So in the original design of Greenwave we wanted to keep it generic. It wasn't aware of these different conventions for test results. 15 00:01:11,935 --> 00:01:17,182 The caller would pass in an arbitrary set of key-values when they ask Greenwave for a decision, 16 00:01:17,182 --> 00:01:22,267 and then Greenwave would look up the test results using the same set of key-values that it was given. 17 00:01:22,821 --> 00:01:30,187 That was the "subject" parameter, which Greenwave has always had, and that's what we've deprecated now. 18 00:01:30,416 --> 00:01:37,521 You can see it in action here, if I send a POST request to Greenwave... 19 00:01:42,378 --> 00:01:50,885 I'm going to request a decision for the "rhel-8" production version... 20 00:01:53,557 --> 00:01:59,359 the "osci_compose_gate" decision context, and subject— 21 00:01:59,359 --> 00:02:05,389 this is the parameter that we've now deprecated— it would look like this. I would say... 22 00:02:05,389 --> 00:02:11,060 "type": "brew-build", and the "item" would be my NVR. 23 00:02:11,060 --> 00:02:17,547 and that matches up with the key-values that exist on the result, like we saw before. 24 00:02:17,775 --> 00:02:24,326 I'm just going to make up a non-existent NVR for right now. 25 00:02:27,781 --> 00:02:35,506 So you can see in the request body here, we've got "subject" parameter, which is this list. This doesn't seem too unreasonable, 26 00:02:35,506 --> 00:02:43,720 but if you remember when we are talking about Bodhi making a request for a decision from Greenwave, 27 00:02:43,720 --> 00:02:52,129 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 28 00:02:52,129 --> 00:02:58,289 that were in the update, and all the differents ways that we record results for different builds. 29 00:02:58,713 --> 00:03:03,928 So that's really the biggest downside with this approach, it's that all of Greenwave's callers have to understand 30 00:03:03,928 --> 00:03:06,633 all the different ways that we store results in ResultsDB. 31 00:03:06,633 --> 00:03:13,511 It adds unnecessary complexity for the other services when they want to make their requests, and also if they want to 32 00:03:13,511 --> 00:03:17,552 listen for decisions from Greenwave on the message bus. 33 00:03:17,846 --> 00:03:25,473 So instead of arbitrary key-values, we've now introduced two new parameters: "subject_type" and "subject_identifier". 34 00:03:25,864 --> 00:03:33,491 If I repeat that same request as before, I'm going to replace the "subject" parameter with the two new ones. 35 00:03:33,752 --> 00:03:36,490 "subject_type" here is going to be "koji_build", 36 00:03:36,490 --> 00:03:41,607 and "subject_identifier" is the NVR. 37 00:03:48,777 --> 00:03:55,459 And if you were reading the output before, you would have seen that 38 00:03:56,405 --> 00:04:01,228 we've actually got, in the response from Greenwave, 39 00:04:01,228 --> 00:04:07,356 we've actually got the new keys appearing, the "subject_identifier" and the "subject_type". 40 00:04:07,356 --> 00:04:10,909 But we also have "item" which is actually the previous... 41 00:04:10,909 --> 00:04:16,743 This "item" nested inside "item" was the slightly bizarre API that we had before. 42 00:04:17,037 --> 00:04:24,044 The key difference is that the subject type has to be one of the subject types that Greenwave understands. 43 00:04:24,142 --> 00:04:28,999 So we've defined three subject types so far, based on how Greenwave is being used in Fedora. 44 00:04:29,162 --> 00:04:32,714 They're written up in the Greenwave API docs, which you can see here. 45 00:04:33,040 --> 00:04:38,125 For each of the subject types, the docs say what the format of the identifier is. 46 00:04:38,549 --> 00:04:43,764 And the other major difference is that Greenwave can now have extra logic associated with each subject type. 47 00:04:43,862 --> 00:04:47,121 So when you ask Greenwave for a decision about a Bodhi update, 48 00:04:47,121 --> 00:04:53,249 it now knows that it also needs to check the policies for each build in the update, and it will enforce those too. 49 00:04:54,031 --> 00:04:57,453 So that makes life much simpler for the caller. 50 00:04:57,975 --> 00:05:05,602 It does mean we now have more logic living in Greenwave, but otherwise every caller and message consumer had to have 51 00:05:05,602 --> 00:05:12,284 the same logic and we think it's better to consolidate it here in one place inside Greenwave. 52 00:05:13,359 --> 00:05:17,336 And lastly, just to add a bit of pizzazz to the demo, 53 00:05:17,336 --> 00:05:25,060 I'd like to show the same thing in action with the message-driven workflow. 54 00:05:25,060 --> 00:05:33,339 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 55 00:05:33,339 --> 00:05:36,175 pretending to be a test result. 56 00:05:36,436 --> 00:05:37,805 So... 57 00:05:38,750 --> 00:05:41,749 I'm going to send a new result 58 00:05:43,020 --> 00:05:50,419 which matches the policy that I was asking for a decision a second ago, 59 00:05:52,700 --> 00:05:55,406 with the same fake NVR. 60 00:05:56,351 --> 00:05:59,936 And we should see, if we refresh the page here, 61 00:05:59,936 --> 00:06:05,053 this is the Datagrepper stage, we've got a new result appeared just now. 62 00:06:05,347 --> 00:06:07,400 Let's take a look at what's in there. 63 00:06:09,193 --> 00:06:21,513 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 64 00:06:21,513 --> 00:06:23,143 that I was using before. 65 00:06:23,958 --> 00:06:28,684 And if we jump over here and request the same decision again, 66 00:06:29,303 --> 00:06:33,541 we'll see that Greenwave now considers all the requirements to be satisfied 67 00:06:33,541 --> 00:06:38,397 because that test result exists and it's passing. So that's great. 68 00:06:38,886 --> 00:06:43,417 But the message driven part of it is actually here. 69 00:06:43,417 --> 00:06:47,100 Right now I'm going to jump over to the OpenShift console, 70 00:06:47,100 --> 00:06:52,250 and we're looking at the logs for the resultsdb-consumer pod in Greenwave. 71 00:06:52,445 --> 00:06:55,020 And if I scroll up a little bit, 72 00:06:55,705 --> 00:06:57,726 we'll see that... 73 00:06:58,899 --> 00:07:06,819 Greenwave found the new result which appeared in ResultsDB for the fake NVR. 74 00:07:06,819 --> 00:07:13,566 And it's decided that now the policy's satisfied, so you can see... 75 00:07:13,566 --> 00:07:16,011 It's a bit hard to read because we're looking at a log message, 76 00:07:16,011 --> 00:07:20,672 but we can see that all results... all required tests passed. 77 00:07:21,747 --> 00:07:23,084 And... 78 00:07:24,257 --> 00:07:29,407 You can see that we have the "subject" key here in the message. This is the deprecated one, 79 00:07:29,407 --> 00:07:32,471 but it's still present for compatibility. 80 00:07:32,471 --> 00:07:36,969 But you can see we also have the new parameter "subject_type" with the value of "koji_build", 81 00:07:36,969 --> 00:07:39,609 and the new "subject_identifier". 82 00:07:39,609 --> 00:07:44,628 So this matches the same parameters that are in the request body when you make a request. 83 00:07:44,628 --> 00:07:52,614 We've got the same in the messages that Greenwave is producing, and it's backwards compatible in the same way. 84 00:07:53,038 --> 00:07:59,002 And of course the message actually failed to send, because we have a misconfiguration in our stage environment 85 00:07:59,002 --> 00:08:02,262 so I hope you'll forgive me for that. :-) 86 00:08:02,555 --> 00:08:07,216 All right, thanks very much for listening everyone. See you next time.