 Hey, everyone, my name is Gerald Nunn. I am the GitOps technical marketing manager at Red Hat. And today, with coming after Jesse's presentation, I'm sensing a trend. So we're going to talk about DevOps in a GitOps world. But really, what I want to kind of get at here is to really get feedback from you folks in terms of your challenges and what you're looking for. It is, from a feature set perspective, this is something that we should be doing in the upstream Argo community. So when you look back at CI back in 2010, the early days back in the Jenkins, Hansen's days, yes, I'm that old, the CI tool essentially did it all. But now with the advent of GitOps and all of the cool GitOps engines and the capabilities they bring, what we're really seeing is a split between CI and CD and using CI for what it's good at and using CD for what it's good at. And that's bringing a lot of benefits. But even though the process and what we're doing is evolved, as Jesse noted in his own keynote, we're still kind of doing the same things the same way. I changed my source code. I built an image. I push it out to a deployment. And it's a very point-by-point deployment by deployment type process. I update my dev manifest. I update my stage manifest, update my prod manifest. I test that particular deployment that I'm doing, but I'm not looking at things holistically when I'm doing that. And this brings a lot of challenges that we see at our customers at Red Hat. One of the bigger ones for me really is about coordinating changes. So I'm doing a new image update. I'm deploying new source code, but it needs a config map update. It needs a secret update to go with it, right? And I want to deploy them at the exact same time when I start rolling them through the different environments. How do I do that? The CI tool is automating source code changes, and it's automating all that, but it knows nothing about what the human has to do in terms of updating things to be compliant and make that work. The other thing that comes into play is dependent applications testing. And there was an earlier question about this in my previous session. I've got a couple of different applications that are dependent on each other, and I want to test them and deploy them more holistically. If we lived in the world with rainbows and unicorns or microservices were perfect and they were infinitely backwards and forwards compatible and you could always just test that and never worry about it, things would be great. But unfortunately, that's not the world we live in for the most part. Most enterprises, well, some can do that. It's not always the case where that's possible. And you are going to have these dependencies where you want to manage these things more together. So like when I deploy app one, I don't want to just test app one. I want to test that app two. We'll still work with app one. And when you look at ARD with CD in terms of our levels of abstraction, right now we have applications. And yes, there's application sets on top of that in terms of grouping those applications. But really the question I want to pose is, do we need more or a different level of abstraction to go along with those applications? At the lower end, you can have a concept of components. We kind of address that with customized components, umbrella charts and hell. But the higher and then we're looking at things more holistically. Do we need something like environments, snapshots? Something that represents more of what you're deploying to and from a target, but something that's more holistic than a single application. And that's really where we're coming from this perspective is looking at things more holistically and how do we do whole environment promotion or maybe snapshot promotion, right? Where you can have related items, be able to manage them effectively and efficiently deploy them together, right? And then as you move through Dev stage prod, essentially be able to test each of those environments in turn from a more holistic perspective rather than a point test that you do for a particular deployment that you may be rolling out at that point view. Now from this approach point of view, there's definitely some pros and cons. The pro perspective is you're testing things more as a unit and moving things as a unit, which is great. The con though is that obviously if you've got a hundred different microservices, that could be a lot of testing and a lot of time to do all that testing and slowing down your CI process, right? So those pros and cons to this approach and what that right level of granularity in terms of defining that superset over applications is something I'm quite interested in hearing from you folks as we go through this. So from a keynote perspective, really, I'm not selling anything. What I really want to get from you folks is your feedback. I want to hear from you folks, you know, is there a need for this higher level abstraction? Because we've done some work internally about how to on this and we'd love to contribute this more upstream and get this into the Argo community as something that's part of Argo. And we see this as something that's needed. But the other hand, you know, when some of our developer advocates are going around to different organizations, we don't always get that feedback that, yes, we need this. Like from a lot of times where we hear is what we're doing works and we're happy with it. So no need for a change. And obviously it can be a large investment to do all of this stuff and make it all work upstream. So we definitely want to hear that this is something folks are interested in before we start pursuing it in more detail. So last bullet point, if you don't agree with any of this, and like I said, you think applications, application sets are all you need and you're good to go, hey, I want to hear that to you. I'm all about wanting to hear the feedback. So that's it for me and I've got no time left. So that's it. Thanks very much, everyone.