config: set operator payloads for v0.8.0 release

[portersrc]

This covers steps 4 and 5 from the release checklist here

[ChengyuZhu6]

tdx test is passed: http://10.112.240.228:8080/job/confidential-containers-operator-main-centos8stream-x86_64-containerd_kata-qemu-tdx-PR/588/

[fidencio]

@portersrc, just one tip, mind the commit message.

Here's a little bit of git etiquette that you can get some inspiration from https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53

[portersrc]

/test

[fitzthum]

LGTM

[stevenhorsman]

Don't we need #274 to be merged first before we take the reqs-payload release?

[fitzthum]

hm good point. i guess the question is whether we can continue the release in parallel (i.e. merge this, tag the subprojects, and pick up the new reqs/operator changes when we do the next bundle update (step 13)). i am fine with waiting for #274, but that will serialize things a bit. wdyt @fidencio

[stevenhorsman]

If the plan is to cycle back around and re-bump this once the operator PRs are finished then I'm okay with that, I just wanted to ensure that people were aware that we haven't finished yet, so some of this work will probably need to be redone.

[fitzthum]

Yeah #280 also will change things. I think it is reasonable to pick up these changes later. It seems likely that a bundle that works with the current operator would also work with those PRs merged. Not ideal to have both things moving at once.

[fidencio]

I just merged this one, there are PRs coming on the Operator side; there may be PRs coming on the peer-pods side as well, but I'm fine on having kata-containers side of the things not moing.

[stevenhorsman]

Based on the understanding that some of the tags will need to be updated before the release is cut, I'm okay with this change.