Good afternoon. Good evening, man. Welcome to the Galaxy. I'll be your captain here in this journey. Christian Hernandez, a technical marketing here at Red Hat. As you see, I have no co-captain today, right? So I guess the co-captain today is you out there watching this. I hope there's no too many cooks in the kitchen here with everyone being a co-captain here. But thank you for joining another episode here. So a few things here today, where we'll be talking about CICD, we'll be talking about GitOps and CICD. A lot of people actually reached out to me talking about CICD and GitOps and how they're related. We've done a few shows, I think in the past, talking about Tecton, last time we had the Argo workflow. The guys from Intuit, come on, talk about Argo workflows. A lot of people doing CI with workflows. I'd like to show today a demo or a high-level overview of how to do a GitOps-ish workflow with Tecton and Argo CD. Before we get to that, I'd like to steal a little bit from Andrew, talk about a little bit on what's top of mind. First and foremost, if you haven't already, please subscribe, share. We'd like to grow the show. I love hearing from everyone all around the world on Twitter, on LinkedIn, people constantly message me. I like that. So go ahead and feel free to reach out to me either on Twitter. Follow me on Twitter. I believe my name is either down here or down here. I always forget when you married there, ChristianH at 1.4. Twitter handle. Get handle as well. Also, remember, subscribe, share. Again, all that cool influencer stuff here. So today I knew I was going to be alone. I had my two cups of coffee, so I'm ready to dive in. I have a little weird tradition of every Thursday I drink two cups of coffee instead of one. People always ask me, why don't you just drink as much as you can? It's like, oh, I don't know. It's just weird. If you treat something like a special occasion, it's actually a little bit more special. So I have it here. So first and foremost, let me share my screen here. Talk a little bit about what's top of mind here. Let me make sure the screen comes up. I think I've already, there we go. So yeah, again, redhat.com slash live streaming. If you haven't already, this is our one stop of everything. You'll have the calendar there. So make sure, you know, never miss an episode or if you're trying to figure out what's going to be what, go ahead and visit that. So little top of mind, like I mentioned before, ArgoCon is coming. First ever, not real ArgoCon. We try to make it a live event, but actually we just decided to make it virtual. So still time to register, still time to attend this event. There's gonna be a lot of cool things going on here. So let me click on the schedule here. It's multitrack. So this is really cool. So like if you're interested in like workflows, Argo workflows, Argo events or Argo CD and Argo rollouts, there's a couple of tracks. The region I'm mentioning this here selfishly is I do have a talk here talking about the stateful applications, right? Argo CD stateful applications. I did do a stream earlier here about stateful applications. This is kind of a continuation of that. So if you see that episode, and if you have the time next Wednesday, 125pm Pacific time, I'll be giving a talk at ArgoCon. So if you can attend that, it'd be great. I'll be going a little bit further in that conversation. So other cool things going on ArgoCon. I know Dan Garfield is going to do the keynote here at CodeFresh. Really cool guy. I work with him a lot in the open get-ups working group. And they have some Argo CD production best practices, another one from Alexander. He's been on the show as well. Talking about Argo CD, he's going to be talking about best practices. So a lot of cool stuff. If you're into Argo CD using the Argo projects for certain things, it's going to be a lot of great stuff there. And I think that's it. I think this next top of mind thing kind of just goes into what was, oh, before I forget, actually, I'm running a survey. It's the next top of mind thing before I get into the actual today's topic here. So I'm running a survey here. I'm going to throw this in the chat pretty soon here is we've been doing get-ups guide to the galaxy for a little over a year, almost two years, almost two years. So this will actually, this December will be the second winter break shutdown that we have here at Red Hat that we're going to take. So I'd like to think of it as two years. And we'd like to see where you guys think about the show, where we want to take it. So just make sure you get to get the survey and take that survey. Give me your thoughts, be as mean as you want. Maybe not as mean as you want, but give the feedback to see what you guys want to see. What more we want to explore in this get-ups journey. So saying that, my last top of mind thing here is that I was actually going to go to DevConf, speaking of events, they just made DevConf virtual. That's one thing. And two is Stephanie the producer is like, please don't be mean in the chat. So yes. So please, yeah, please don't be too mean. But we want to hear the truth. And actually, I was actually going to give a talk about actually a workshop about CICD and get-ups in Argo. So one that turned into a virtual event.  So I'm actually only going to be doing a talk for DevConf as well. I'll give you that information as soon as I I'll probably tweet out that information as soon as I have more on that. So that being said, so let's talk a little bit about OpenShift, CICD, and Tecton, get-ups. How does all that look, right? And so I believe you guys seen this presentation before. It's been shared out. This is a public presentation. So, you know, I'll end up sharing it too. I'll probably tweet this out later on. We shared this presentation out before. There's nothing too hiding here. I'm not going to go over through this presentation, right? Bit by bit. But I do want to call out a few things, right? And so when we talk about CICD, right, and traditional event-based CICD, you know, a lot of those same concepts still exist in a Kubernetes world, the cloud-native world, except now you can go even further, right, extend it even beyond of what a traditional CICD is, CICD looks like. Just from the sole purpose or the sole fact that Kubernetes is a declarative infrastructure, right? So if you guys have been watching the show, we're all about declarative, right? We're all about being, you know, if you're watching the show, I hope you're all into the get-offs methodology of being declarative. So we just kind of take that and essentially run with it, right? So like making everything declarative. And so when here at Red Hat, when we were, you know, we have OpenShift, which is the enterprise Kubernetes offering. We're trying to reevaluate of what does CICD look like in an OpenShift world, right? And so, you know, a lot of people are used to things like a platform like Jenkins or CloudBees or, you know, something like that, which, again, there's nothing wrong with that, but a lot of people are in the traditional sense of having a platform to do their CICD, whereas now with Kubernetes and OpenShift, that can be part of the platform itself, right? So, you know, the platform that is delivering the application can also be the platform that does that build and does that check for you. And so, you know, if, so now that we have a platform like OpenShift that's declarative, then you can use some of these tools to have a declarative continuous delivery, continuous integration aspect of it, right? So I'm going to jump around this presentation, right? So don't let me make a little bigger here.  So let me make this just a little tiny bigger. How do you hide the, can you do this? Oh, there we go. Learning things new, alive. So we have a continuous delivery. Let me jump around here until I get to the tecton aspect of it, right? So the tecton aspect of it is the idea is having a kind of like a serverless aspect to a CI, right? And so you have the concept of having builds happening on demand only when you need them, right? Versus a traditional kind of like CI process where there's like a platform that does the builds for you. Tecton takes the serverless aspect of it to where it only comes up when you need it. So you want to do a build. That's a task, right? Each task has an individual step, right? Collection of tasks. It's called the pipeline. We've done a show with Tecton before, so I'm kind of going to gloss over this here, but kind of the idea is that you have a step that does a thing, right? And a collection of steps is called a task. So like step one is do this, step two is do that, that sort of thing. And a collection of tasks is called a pipeline. And I'll be going over kind of like what my demo, you know, how all that looks, right? Because the idea is that these are reusable, right? These are kind of like, you can specify a parameter, right? For example, like if you need to do a Maven build on something, you just, you know, if the Maven builds always the same, then maybe you'd make it a parameter of you just pass it the Git repo, for example. And so we take that concept, right? Okay. So like we have like kind of a cloud native serverless CI CD, right? Because Tecton does technically do CI and CD, right? But let's just kind of focus on the CI process of it, because we're doing the CD aspect of it with Argo CD, right? And so if you've seen the show, Argo CD, don't have to get too much into it, is the fact that Argo CD is the GitOps controller, right? For OpenShift. That's included in OpenShift that makes, not only does CD, right? Continuous delivery, continuous deployment, but make make sure that, that drift detection is always happening. So I'm not going to go deep into that, guys should already know, right? If you don't watch past episodes, right? Stephanie, Stephanie the producer, I'm going to call her. Stephanie the producer asked me, hey, there's any sharing links? And I actually forgot to show this link. So sorry, Stephanie. All right, put that in the chat, red.ht slash GitOps, hash past episodes, subscribe and like all that good stuff. So let's go, let's focus in on how does CI, CD look like in the GitOps world. So let's look at this guy right here for a little bit. So best practice is that you're always, you're always looking at, you always have at least two source repositories, right? You get repositories, right? You have the source repository of the actual application. That shouldn't be any different. That actually fits nicely in the GitOps model, but that doesn't really change in a GitOps model, actually, right? Because we say that you have, you have to separate your source, Git repository from your configuration repositories, what we call it. The, that separation, I've always thought that you would have, it's better to have it in one repo, right? The code and its deployment manifests. I quickly found out that that is really hard to manage. So I've always said, split it out. I've talked to hundreds of customers who always, because there's a contention where there's some customers that just say absolutely no, I want it all in one repo. And I say, okay, that's fine.  So just, just trust me on that. I actually think you have multiple ones, right? You'll have a config repository specific to the cluster and a config repository specific to the deployment of the application. So I think you should at least have three, but we're going to keep it a little simpler than that. So you're going to have at least two, right? You have a config, Git repository, source code repository, right? And they're going to work in tandem. And so the idea is that since you have two, they each kind of have an independent life cycle, source code repository where that life cycle is going to stay the same. Really, right? You're going to, that process is going to stay the same whether you're using GitOps or not, I think for the most part, it'll stay the same. The config Git repository, I actually have an opinionated way of configuring those, whether it's the config for the cluster or the config for the deployment of the application. And it's something called trunk-based development, right? And so let's talk a little bit about trunk-based development. This is also another point of contention. One of my ex-co-workers, right? We still keep in touch, says that he does a lot in his current job with customers. He does a lot with ArgoCity and Tecton. So I wonder what he thinks about that if you're there, Nick, I know you'll pipe up and disagree with me because we're both opinionated guys. But just in short, trunk-based development is something that I use with the config repository. So this guy right here, not the source code, that's going to have a different life cycle than the config repository. So for those that don't know, let me drop this in the chat again. Sorry, Stephanie, the producer. You need to be, yeah. Yeah, so Benjamin says ex-co-workers still keep in touch. Kind of sounds like a friend. Yeah, so I guess, yeah, I have a friend of mine, ex-co-worker and still friend. So you're absolutely right. And so back to this trunk-based development. So back to trunk-based development. So from a high level, the trunk-based development means that you have a trunk that is the branch that you're deploying from, right? So I like to distill that down that basically you're deploying from main, right? Here it says master, get now switch to main, main, right? Doesn't have to be main, doesn't have to be master, but I'm just going to use that as an example. It could be production, right? That could be your trunk, right? Whatever the trunk is. And you have different release branches, right? So you have different like feature branches. So feature branches are basically things that are going to go back into trunk and things that are going to be deleted because release feature branches are short-lived essentially is what. So with the trunk-based development here, trunk-based development at scale is best with short-lived feature branches. So that's kind of like the idea, right? Like you have the trunk, you have main production staging, whatever, right? Whatever it is, I'm going to say main again, right? You do, you don't commit to the release branches, right? You do your work in the release branches and then it gets committed back down to the trunk. And in the trunk that gets deployed into production. So this is like one of the things that I find a lot of people are doing with going back to the presentation with the config git repository, right? With the source code repository that has its own life cycle that has that cycle is independent and different than the config repository.  That'll have, that'll have its own life cycle.  So not going to go through all of this here. This is a great read, especially if you're looking into your git workflows, whether you're a dev, on the dev side or the op side, or, you know, SRE, this is a great read about how, well, what the idea is behind trunk-based development. So if you haven't seen that, that's what this config repository is, right? So now let's look at the, this workflow. So I've been talking for a while. Let me take a quick trink. So what ends up happening is that someone makes a, a commit, right, to something, right? So it's to code that's going to trigger a CI process, right? So the CI process does something with it, right? It does everything that you would think with CI process, but it builds the application, does a test, you know, once the test passes, it pushes that image to image repository. In that same CI process, there's going to be a change to a config git repository, right? So actually in the CI process, the actual CI process is committing to your config git repository, right? Sounds a little scary, but we'll go through in detail in the demo. Once that is done, the GitOps controller, in our case, it'll be Argo CD. We'll see that change and it'll act on it, right? So it'll say, oh, hey, there's a new image update that was made to the deployment configuration. Let me push that into whatever environment that you pushed that into. CI process can do other things like create a pull request instead of committing directly. That's, you know, part of the little demo that I'm going to have here, that's going to happen, right? So really here in a GitOps application delivery model, the magic is really the CI process interacts with your Git repo, with a configuration deployment Git repo, once a build a success. So this can happen in any step of the CI process, but usually happens towards the end. And it's usually either a PR or a great direct commit to a specific branch, right? Or a feature branch. And so I think I'll go into the demo and then I'll show you how this kind of looks like from another view here. So here, let me... So here, what I have here is I'm going to drop it in the chat. This link I did give to Stephanie, the producer. So I did prepare at least for this here. I'm actually... So this is the CI CD demo that I have. You guys can take a look. There's actually a Helm chart for it. So if you're running OpenShift 4.7 or newer, this will work for you. And it needs to be a freshly installed OpenShift cluster. But this is kind of like what I was going to go through in DevConf, but it looks like that workshop's not going to happen. So that's why I decided to do this stream. So here, you can look at how I'm doing some of this demo here. And again, it's a Helm chart, so you can just add it and run with it here. So let me log in. And I'm actually going to log in as a developer. So let's carry here. Developer. And good. Come on, skip tour. All right, demo guides are with us. Let's log in here to Argo CD. Log in as developer as well. All right, there we go. Cool. So the way this is set up... So I actually logged in as a developer. I'm not a cluster admin here. I actually deployed my own... So here, I'm in welcome get ops. Let's go to... I'm sorry to hear. I actually deployed my own namespace scoped Argo CD instance. So that's part of the Argo CD. So if you go here, let me clear this. Get Argo CD. All right. So this is... OpenShift GetOps is the Argo CD that manages the cluster. And this is a deployment of my namespace scoped Argo CD. It's what we call it. Or... I guess, yeah, namespace scoped Argo CD. We had another name. I forgot. If you guys remember, we had another name for it. You drop in there. I think it's called Project Based. Not sure. Anyway, this is... The OpenShift GetOps, that kind of just takes care of the cluster as a whole, but I'm actually going to focus on... As if I'm a developer, I deployed my own version of Argo CD using the GetOps operator to a specific namespace. So this namespace, I'm going to call it WelcomeArgo CD. So that's what this is here. And that's what this is here. So as you can see that I have different environments set up, technically too. I have Dev and Prod, right? And I have a pipeline that's also being managed by Argo CD. So I have Dev and production here. Let me go to Pipelines. And I have a pipeline. So this pipeline... Let me go here. It does a few things, right? Let me get this a little bigger. This actually takes a while to run, so I won't talk about each individual step until I actually fire it off. But I have Pipeline here that basically builds and deploys the development, and then I'm going to promote it to production once things are going smoothly, right? I have this app here, DumbApp, right now it's shouting green, right? This is shouting green as well. And so this is production. This is Dev. And I have a git tinstance. Let me log into this. Oops. Here we go. All right. Yeah. So I hear, as you see, I have two repositories. I have... Yeah. So I have two repositories here. I have the actual application, right? The Welcome app. And this is just that application running, right? So this is like a static PHP page here. And I also have the deployment, right? So now, as you can see here, I have two repositories. One for the application and one for deployment here. And here, deploy an app. And then the Pipeline, right? So the Pipeline actually lives in the deployment, I believe. Yeah, Tecton, right? So I actually... So I'm kind of using everything declaratively, right? And so I'm using Argo CD to deploy to... I use Argo CD to point to the deployment repo that then creates the Dev, the Pipeline, the production. And that's all self-contained here. And so usually the first step here is let's make a... Let's... Do we have time? So let's make this a little longer here. Let's... Now this is deployment, right? We want to make a code change. So let's go to the application. And then let's make a code change here. So let's... Can we create a branch? How do we create a branch here? There's one branch. I'm logged in. Do I have to do it through the CLI? I thought you can do it here. If not, no big deal. New pull request? No. New pull request? No, because you need a branch for that, right? I thought you could do it in GitT. Maybe you can't. Oh, okay. I can do this. So let's make the edit and maybe that'll create a new branch. So here we have green, right? Say we have green and let's... Instead of blue-green, we're going green-blue. Or let's go yellow, right? Let's do another... Why not? And here... Yeah, create a new branch. There we go. Let's go here. Let's call this... Get off the Galaxy branch. Right? For profile change. So here I create a pull request. Right? Changing to yellow. Okay, pull request. Cool. All right. So now we have the application, right? I was a developer. I made a pull request. They called my hat, right? I'm a different developer now, right? I'm the architect. I'm like, all right, this looks good. Files changed. All right, yellow. Yeah, that's what we wanted. Looks good to me. Oops. And then let's go to merge pull request. Right? Reviewed. I can do... It looks good to me. So this is merged, right? And so what this does is this... If I go down the pipeline, is this kicks off another build, right? A lot of people ask me, how does build get kicked off when you commit to that? Well, as you probably already guessed, there is a... Where's my repo? Let me go back. There we go. There's a web hook, right? So let's go to web hook. I have a web hook. So a tecton has the ability... They call it event listener, right? To set up an event listener. And that just basically hits the web hook to fire off what we call... Let's go back here. A components token. Let's go to trigger template, right? Fires off a trigger template, right? So this trigger template says, hey, when an event listener hits me, I want you to pass these parameters to this pipeline. Let me go back to token here. And that pipeline is defined here, right? And so basically, it just takes that trigger template, takes that template, it feeds it into the pipeline with those parameters. And you can do really some pretty cool things with these parameters. You can do... You can extrapolate things from the payload, right? So like if you want certain information from the payload, you can take those as well and pass that to your pipeline as well. So here... So first thing it does, it just clones the repo locally, right? First step is always the cloning. So once it clones the repo locally, it'll set the image tag. So this is basically... It'll set a variable, right? So it'll say, okay, I'm going to set this commit as a tag, right? Because you want to be able to differentiate the tags of what's in dev versus the next environment, right? Between environments. I don't like floating tags, things like dev, things like colon dev or colon prod because that's kind of an anti-pattern, forget, right? Because in get, you want the source of truth, right? Because floating tags can change whereas things like either the SHA or like a specific UID don't. So you have that. Once it cloned and sets that variable, it'll actually do a build, right? So here's an aspect. So this is one task that has many steps, right? It has the step of building. So I'll actually build a container. It'll actually push the container to our repository here. And then my last step is basically take some of those, like the SHA, right? And load it up into a variable here. So here, I'm tagging latest, right? Even though I'm not using latest in my pipeline, I figure I'll tag to latest in case someone wants to, you know, play around with this image and they just want the latest doing some testing, right? Once I do that, I'm going to clone the deployment repo, right? So here, I just do, I was just, here before I was just working with the software application here. Now I'm actually cloning the deployment repository. And what I'm doing here is I want to have it here so that way I can interact with that repo, right? So first, I did a build on the application repo, and now I'm cloning the deployment repo. I'm going to work specifically with this guy here. I'm going to patch dev. Essentially, I'm running a customized edit. What this does is essentially is going to update the image to the new version here.  So here, since I'm working with dev, and I'm probably doing a lot of iterative changes, I don't really care about doing a PR here. I just commit it to dev, just commit it to that, because I want to see my change right away.  If I look at the customization file, yeah, there we go. So the customization file sets the new tag. So it says, hey, I want this image, I wanted to use this new tag, which I should say in here. Yeah, one DD, one DD, right? So it'll, it updates the tag. And so when it updates the tag, it actually deployed it, right? So like, go refresh. I think, yeah, it already did it while we were talking. I wonder if you can see the, yeah, so here, this is the last sync was done, one DD, right? So it's there. So that actually already deployed. So if I go here, this should say yellow, let's cross our fingers. It says yellow, sweet. But in production, it's not yellow, right? Why is that? And so it's because in my workflow, I'm actually going to patch prod, right? Do the same thing. Instead of doing it in dev, I'm going to do it in the prod folder. You know, one DD, there it is. But I'm actually going to create a branch, right? This is my feature branch. This is the branch that I want. I don't want it directly in production just yet. Right? I want to, I want it in dev. I want the changes in place. But for prod, I want to make a PR because I need other people to look at it, right? So this is the process here is the process here is making a PR. So that way you kind of have that stop gaps or feature or gating, right? This is kind of how you would do a gating. So PR to prod is here. Oh, it looks like we're getting rated. Nice. Welcome, everyone. So here I make a PR to prod. And so we got a PR to prod. And here we can go to the repo. And you can see the PR is already there. So we have a PR to oops, let's go back here. So this here, it'll show you that in my production folder in the customization, that's the file I want to change, right? This is release 1DD. We want that here. And then to go back to the conversation here. So here, I would go into switching my hat. I'm an SRE. I'm whoever, a release manager. All right. I'm looking at this. This looks good. Now here, this is the part where it gets where we can kind of think about this a little bit. The here, we may, we may or may not want to merge this, right? So part of the pipeline, let's go back to the details and see where this here, you know, part of PR to prod can then trigger yet another pipeline that tests this right in production. It doesn't maybe, you know, this is kind of like a simple use case, right? So before I click merge, I want to, you know, kind of talk about how like other things you can do, right? So here, when it does a PR to prod, it can trigger yet another pipeline, right? Because it's just tecton, right? This is just, you know, it's all, it's all web hooks, right? So here, you can just web hook into it yet another pipeline that does yet even more testing, right? So like, hey, a pass dev, that's cool. You made a PR to prod, but we don't want to just merge it, right? Without testing. So this can then trigger yet another pipeline. I just want to mention that because, you know, every time I kind of just, you know, talk about this from a high level view, people go, well, wait, you know, what about other pipelines? It's like, well, yeah, you can do other pipelines here as well. You can chain these together. You can have either one big pipeline run or many little ones, right? You can have slack ops where it tells you it's something passed or something failed. All that good stuff. So but here, let's just say, assuming that it triggered another pipeline, it did all the testing and assuming all of that passed, assuming that, you know, someone did peer review on this stuff here. Maybe I want to merge pro requests, right? And it should do looks good to me. All right, let's merge pro requests right here. What I like doing is I delete this branch, right? You may or not want to delete it. I'm following trunk based, right? As soon as I merge that feature branch, I'm delete it shortly feature branch. I do that. I'll leave that up to you, right? I'll let you do that. You know, that I'll let I'll have you your DevOps team members here argue about whether or not to keep that. But for me, since we're following trunk based, I'll just delete that. We don't need to hang around. And so once you do that, I'm just going to refresh this, right? So usually the reconcile loop takes three minutes for Argo CD, right? So Argo CD has three minutes, that's adjustable, right? You can adjust that. So instead of sitting here for three minutes, I'll just hit the refresh. So it checks. And as you saw, it deployed that application. So here this is product. Sorry, this is dev. And this is my, my full production here. Now it's yellow, right? So now we are now they match, right? And so this is kind of the way to quickly do iterative application development with getouts, right? So here I actually so if you notice here, I didn't actually interact with Argo CD, all that often other than hitting refresh. And I didn't really interact with OpenShift, all that much. Everything was driven through get, right? So I'm using get t here, for example, but here I'm using get. Although this process, if you think about it was done via get, and I could even distill it even easier than that, I could have actually technically use something like VS code and just start a committee through a VS code. So in all the automation is happens that happens in the background there, see? So this is kind of how you would use here, you can see the history, right? Succeed, succeed. I had some issues here. I don't know if you guys had issues with the other day. We had an outage from our, I think it was one of our registries, registry.redhat.io, right? I was like, why is this taking so long? Why can I pull these images? I'm trying to prepare for a stream.  Anyways, they fixed that. So that's just another thing to look out for, right, is where you're keeping your images, right? A lot of people like to use something like Quay, or if you're an England key, right? Does it call it there? In Australia, I think in Canada as well. I don't know, I think there's some Canadians watching. Do you guys call it Quay or Quay? Drop that in the chat, if you guys know. But some of them like to have that in-house, right? So that way you don't run into the problem that I did. And I think it's a good idea is to have your in-house registry server, right? Even if it's just mirroring, right? So you can even have it as a mirror. I think that's another cool idea. Actually, that's another cool show idea is to have mirroring and mirroring Git repos, right? So the idea, someone brought this up, the idea of having a Git repo mirror your actual Git repo. So that way, when you have a network cut out or have the source of truth closer to where your clusters are, right? So this person I was talking to is a company, can't say the name, but they manage hundreds of clusters all around North America and they decided to use Git mirrors, right? Because they don't want an outage in their Git system. I think they're using a GitHub or Git lab internally. They don't want that going down to make the other systems going down or a network add outage, right? To mess anything up. So they actually had set up Git mirrors. So maybe I'll do an episode of that. That'd be kind of cool to explore. So anyways, back to the topic at hand. So here, this is kind of what I had in mind. Some other things to consider. Now I'll actually bring up the really, really cool slide that I wanted to show in the beginning, but I thought I think it's better to show this from a high level of you. So Nick, if you're watching, this is probably what you wanted to see. The other stuff was probably too high level for you. But here, this is how to use some of these, some of this offering, some of the OpenShift offering, right? So here, you can see how all the OpenShift offerings, the Red Hat offerings, all the technologies that we have here can be used together, right? And so, still same idea with the application Git repository config Git repository, you'll have one or many application Git repositories and one or many config repositories. And oh, hey, Tiger's here. Hey, Tiger. Tiger the intern. I guess you're not the intern here. So we got here the config here. You have one or more many config repositories here. And so the CI, our vision is we see it as tecton, right? And that's kind of like your CI process. Outside of GitOps, tecton can do CI CD, but in the GitOps world, right? In our journey here, we focus on the CI aspect of it here. You could also use Argo workflows, right? If you don't want to use tecton. And then doing Argo CD for the reconciliation of it as well, right? And, you know, we kind of went through that. But on top of that, you want to do something with security, right? So that's when advanced cluster security stack rocks comes into play, right? And that's how this interacts with your, not only your image registry, right? For your CI process, right? Because you can have scanning happen in your CI process. You can have scanning happen in an image registry as well. And you can make sure that those clusters that you're running are in compliance, right? So this is kind of where ACS fits in here. We had Michael Foster from ACS, really, really cool guy came on the show, talk about ACS. This is kind of where the ACS aspect fits into it, right? So the CI process interacts with, or I guess ACS interacts with your CI process in vice versa. And then you have Argo CD here doing the reconciliation for your applications, right? So you want to be able to deploy, like we saw, right? Have Argo CD making sure everything's in constant sync, making sure that there's no drift detection as well on top of doing the CD process of it as well. And then you have the advanced cluster management. The advanced cluster management here, or ACM, right? Right at ACM does life cycle management of your clusters as well, right? So whereas at Red Hat, we have the view of Argo CD is meant for a get up workflows, which kind of overlaps with ACM because ACM does have a get ups component. But ACM, I always tell people, and it's always, you know, whether it's people here at Red Hat, whether you're in the field at Red Hat, or really just customers here, you know, I always say calling ACM a get ups tool is really short selling ACM, right? So you're really cutting ACM short, right? You're like, I don't see the difference. I'm like, you don't see the difference between ACM and Argo CD because it's much more than just that, right? Like you're talking about cluster life cycle management. And whereas Argo CD is just a reconciliation, get ups tool, right? You can make it do other things, but really ACM shines in you manage the life cycle of your clusters. And you can use it in conjunction with ACS to enforce policies. It's really, really cool. So then here you kind of have a bigger picture of how that looks like. And so you can have ACM interact with your CI CD process to spin up even additional clusters. This is kind of think about that for a second. When you have like a want to test a feature branch, you can have ACM spin up a cluster, right? Interact with your CI process to spin up a cluster and do the test that way, right? Deploy the application on a test cluster before actually promoting it. You can do that with ACM. Can't do that with Argo, but you can definitely do that with ACM. And so this is kind of how that bigger picture, how everything fits together in that bigger picture. So everything here in the middle is batteries included, right? So for those people always ask me like, oh, how much are you charging for Argo? How much are you charging for Tecton? I was like, no, that's included. Use it supported. Batteries included in OpenShift. If you need anything beyond that, right? You'll definitely need something for ACS and ACM. That does have a skew, but you can always test, for example, open cluster management. That's the upstream of ACM. And StackRox is the upstream for ACS. So this is kind of the idea behind that, right? So that's kind of all I wanted to share. I don't know if there's any questions I'm looking. Looks like the Raiders may or may not have left. Thank you for joining anyways. Tiger is there. So Tiger the intern, now co-worker. So there you go. So we like hiring our interns here. One thing I did want to try is that, so notice how, so it, you may or may not have noticed it, but if you did notice that how I had to click refresh for this to do the reconciliation, right?  So let's kind of look into that for the, let me say we can do some exploring the last few minutes here. Web hook. There we go. There we go. Get web hook configuration. So here we have, so here it says you can do web hook configuration for the application here. So let's go. So the idea being that in the pipeline, let's go back to the pipeline. Once the patch or commit, where's the commit to, yeah, commit to dev. The commit to dev step, that can also hit a web hook, right? So I was thinking maybe we can hit that web hook to do the on demand reconciliation instead of waiting three minutes. We may run out of time, but let's kind of just start that journey. I haven't done this yet. I'm doing it live. So we'll see if I fail miserably here. So Argo CD slash API web hook. So how does that even look like? So let's try to, can we hit that payload? So here, there we go. Hopefully that wasn't too loud. So let's curl dash K. And here it says to do API web hook. Unknown web hook event. That's a good sign. Let's go to see what it does this year. Bad request, mark bundle, not supporting multiverse. It's by expecting a payload, but that's good. It looks like it's there. So it looks like the web hook is there. It's listening for a web hook. It's not, but we're not sending it the right information. So that's good. So at least we know that the web hook is there. It's just we're not sending it the right information. So probably it's expecting a trigger, but I wonder what the payload looks like. I would like to see if I could just curl it once to see if we can make it go. See here. Yeah, it doesn't tell you what the payload looks like. So JSON forum URL encoded. So if anyone knows, so if any of the engineers are on, sometimes the engineers are. So it's application JSON. The value is not supported by libraries then. Okay, so I have to use application JSON. So let's do some Google foo, see if we can find it here. Argo CD, web hook payload, notifications, that's for events. Maybe this will help. Ah, here we go. Web hook event source. Oh, this is Argo events, not Argo CD. Yeah, Bing. Does Bing have it? Let's go Bing. Not right. This is what happens when you do it live. Argo CD, web hook payload. Interesting. Let's look at the source code. We probably won't get this working because we have such a short time, but it's interesting kind of look at this here. Web payload. So interface. This is looking for web hook URLs. Revision, okay, so we need to provide it to revision. So I guess like main in our case. Parts revision, touch head, okay. This is for GitHub. Oh, what about Git T? Is there like a generic one? Yeah. Yeah. So using Google to find Bing. I actually didn't know the URL for Bing. So it's, I should have thought it, I should have guessed it was Bing.com here. Gogg's client. Oh, maybe a Gogg's client would be, is probably what we want because Git T is based on Gogg's. Let me see here. And this is just, I think it's just the, yeah, this is just a documentation. Yeah, I may have to, we may have to, it'd be interesting because I think this would be a good update to that CI CD demo for it to actually hit the web hook. So this might be homework for me because I don't think we're going to figure this out here because here it actually, so if we go back to the documentation, where's the documentation? I always lose the documentation. There it is. This is talking about actually on a commit, but I actually want to use the reason I'm using curl. So this kind of is my thought process. Go back a little bit. The reason I'm using curl is because I actually don't want to put it in, at least not initially, in Git. What I want to do is I want to put it in tecton because in tecton commit to dev, I want another step or another task. I'm not too sure. Another step that hits that web hook. And then, and maybe for the second one, the second reconciliation, yeah, when someone commits to main or whatever branch in my production instance, then yeah, then maybe I want that. But I kind of want to see what the payload that looks like. So that might be homework on my end. We're running out of time here. Let's see here. So if there's any questions, I don't see any questions here. So I just see just me and Tiger interacting. So again, Tiger the intern. I wonder when that intern is going to drop off to your title, Tiger. I'm used to calling you the Tiger the intern because you're actually not an intern anymore. You're in the Tiger the engineer. How about that? How about this? Tiger the engineer. Well, I'm going to transition you to Tiger the engineer. Yeah, being captain here and get off the galaxy, I can make those promotions here. So Tiger, you're no longer the intern. You're now the Tiger the engineer. So cool, cool. All right. So doesn't look like any questions coming down. We're coming up short on time. Maybe next time I show this whenever I'm on the road, probably the next time I show this on the road, I'll have those web hooks showed up. I'll post this on social media. So speaking of social media, make sure to follow me, Christian H814 on Twitter. I'm also on GitHub, the same handle. So be sure to follow me there. I'm always posting updates to shows. Maybe I just, I've been wanting to start a blog. The thing is, I'm a better talker. I mean, you may have a different opinion about a better talker than I am a writer. I always, I've been wanting to start a blog kind of how Andrew does to kind of, but I always definitely do update on Twitter. So make sure to follow that. Make sure to like and subscribe and share with others. Fill out that survey if you haven't already. I appreciate everyone who has. We've gotten some good feedback so far. Leave that open to the end of the year. Update in terms of shows. Let's see if we can find it here on the calendar. I don't think it goes that forward. Oh, it does. So Thursday, December 16th, get off Skype to the galaxy. That'll be the last show of the year. We are going, we're taking a, we have a company shut down here at Red Hat. It's something, you know, we do a recharge day every few days, but then towards the end of the year, we have like a week where we basically do a shutdown, Skeleton crew sort of thing here at Red Hat. Even after IBM, we're so continuing that for that tradition. So this will be the last show of 2021. Have something special lined up for you, right? So for those who are watching here, I'm going to be doing the top 10 best things and get ups. Be going through kind of the kind of some of the cool things that we've done through the year. I figure kind of close out the show doing something really, really cool about just kind of talking about the year, right? And then hopefully talking about the year ahead. So with that, thank you. Thank you, everyone. Again, remember, reach out to Twitter. If you ever have a question or anything like that, I'm also on the Kubernetes Slack. Same username, Christian H814. Find me using that handle everywhere. And yeah, I think that's it. And so like I close out every show, if it doesn't get, it's just a rumor. Thank you, everyone. Bye. Enjoy your day.


I will always own a gaming PC because PC is the master race. How else will I play the latest Battlefield game or revisit old classics like Starcraft 2 and Mass Effect? I'm also happily married to my Android Samsung Galaxy S21 Ultra which I use to shoot 90% of all the content I produce for our channel. In fact, I'm shooting with it right now. In addition to a desktop and a cell phone, I found it very handy to always have a laptop in case I need to travel and take my work with me or if I want a change of scenery and ride at a coffee shop. That's why in 2015, I bought the Surface Pro 4 but which recently began a slow death due to a defect in its production. Hi, I'm Rafael from Hardware Sugar, I'm a lawyer, writer, and a PC store owner and I just made my best purchase for the year, the 2021 12.9 inch M1 iPad Pro. I've stayed away from Apple devices for the past five years or so because I find it infuriating that I am stonewalled from doing things as basic as moving pictures to and from my iPad using Windows Explorer with the album names identified and not just the dates by the way, or being unable to customize my home screen with independent Google spreadsheets like my S21. Android for mobile and Windows for desktop to me have been a perfect combination because they communicate so well with each other and promote the freedom to do a lot of things without being shackled by a user interface like iOS. Nevertheless, in spite of this, I believe most Windows and Android users looking for a laptop or tablet have more to gain by making their next device an M1 iPad Pro with the Magic Keyboard. There are a lot of reviews out there expressing what an iPad experience in 2021 is like for those of us who either have never owned an iPad or who last owned one years ago. And so I don't find the statement, it's an iPad. Very helpful. If you want to see a more traditional review, you can check out the Verge and MKBHD's full review of the M1 iPad which I'll link in the video description. This video is meant for people who have yet to make the leap from Windows to iOS as their main or even secondary device. Plus, this won't be your typical iPad Pro first impressions video as it presupposes some things which a lot of iPad veteran jockeys already know. Nevertheless, even a seasoned iPad user might find some of my input useful especially if you are looking to jump away from iOS and into a Windows or Android tablet instead. Talking about the reliability of the M1 begins with a track record of what came before it. My first and last iPad before this was the second generation iPad way back in 2011. It was the single most important thing that helped me get through four years of law school and the bar examinations. Even a decade ago, the iPad was already a reliable and powerful piece of hardware which simulated pen on paper annotations long before the Apple Pencil through the use of the Goodreader application and a third-party stylus. Handwriting as we are taught in law school, and I can personally vouch for this, helps in memorization and most importantly helps in internalizing complex concepts. If I was already impressed with the handwriting experience 11 years ago, then I knew I was going to be in for a treat with the M1's 120Hz refresh rate screen and the Apple Pencil. The 2011 iPad had crazy battery life which allowed me to study 6 or 7 hours straight and yet still maintain enough juice before needing to plug in when I got home. I was a really liberating feeling knowing that I didn't need to bring the charger with me to school because I was always confident in its ability to keep going. Even after heavy years of use, I never felt the battery life changed all that much. In fact, before buying the M1, I borrowed my mom's 2015 iPad Pro and my dad's 2014 iPad Air 2 to test how well these devices have aged over the years and concluded the same findings which is that the amazing battery life and the lag-free user experience is consistent across my iPad's successors. Each product is an opportunity to win a customer over not just for the latest model but for its successors as well. Momentum is crucial when it comes to being productive. I love how with my M1 iPad Pro that there is zero lag and zero buffer when it comes to switching between apps you used the day prior or even those you haven't used in ages. If I'm typing a script late through the night, I can get right back to where I left off without having to turn on the iPad or even wait for the program to load. It is true that Windows boots up so much faster now in general with an SSD but even with an SSD, there is a boot up time and the occasional annoying pop-ups which you may or may not want and then there is the ever so slight time it takes to get the program you want going.  The battery life on laptops running Windows in my experience have been abysmal. If you choose to flip the laptop down for the night when it has a 90% charge, you should expect it to be 90% or 89% the next day. This has never been true for me regardless if I got an ASUS or a Microsoft laptop. Not everyone has the same problem as me. I assume there is a faulty driver in Windows or a program that I need to remove to fix the issue. However, the iPad never has this kind of issue partly because of the lack of freedom Apple imposes when it comes to user access and customization, which in this case is actually a pretty good idea. When it comes to file sharing between iOS and Windows and Android, it isn't as clunky as it was 10 years ago and you can see that Apple is trying to play well with others. I still want to be able to drag and drop Microsoft Word files or any other files for that matter straight from Windows Explorer into my iPad, something which Android has allowed me to do for the longest time. I dislike having to use iTunes very much. However, I am immensely impressed that you can now plug in an external hard drive into an iPad and be greeted with a Windows Explorer type of interface through iOS's files app. I feel a little ridiculous saying this because it should have been standard 10 years ago but which only became a reality in September 2019 with iOS 13. It is important to note that if your older iPad or iPhone doesn't support iOS 13, then this feature isn't available to you. Wireless file sharing through the FIM app, which is available across all three platforms, allows me to move files wirelessly for free between my PC, Android phone, and my M1 iPad Pro. Being occasionally gives me errors but for being a free application which allows me to transfer files quickly and with minimal iOS red tape, makes it a fantastic alternative to Apple's AirDrop which doesn't work with any of my other devices. Being able to receive files from different operating systems seamlessly back and forth with less restrictions and being able to organize them in a more desktop kind of way is proof enough to some that the iPad has become the laptop replacement they have been waiting for or at the very least that time is on the crooks of happening. Whether you fall within the former or the latter's group depends on your current needs. I have some friends who have to use software which just isn't compatible with an iPad. I always had this belief that most iPad apps were amazing and fun to use at first but were nevertheless programs I could live without in my professional life. They were these hollow shells which resemble the usefulness of Microsoft Office or Photoshop but which never match them on actual substance. This however doesn't seem to be true anymore and even my original belief that iPad apps need to be just as good as my PC programs is an unnecessary comparison. There is no program on my PC which can simulate the satisfaction I get from free thought outlining using the endless paper app nor can the iPad run of course the upcoming Battlefield 2042. Let me briefly go over just some of the apps which have made a big impact on me as a new iPad Pro member. Although not an app, I was very happy to find out that iOS can now natively make any document, screenshot or picture into a PDF by simply going into print, zooming in and then having it open in an app of choice as a PDF. 10 years ago, I either needed to download a sketchy application to do dock the PDF conversion which not always work or use my PC to convert it through Microsoft Office and then email it to my iPad. Endless paper allows you to handwrite and draw infinitely on the same canvas. You can quite literally zoom in as far and as close as you want and add anything you want along the way. It is extremely liberating especially coming from someone who has restricted himself to old-fashioned outlines on Microsoft Office for the past five years. Notion is the everything app of my dreams because it can simulate being my planner for all my upcoming videos, my checklist on the go or even a text sharing application from my PC to my Galaxy S21 or my iPad Pro. It is an extremely versatile application which can do so many things well that the only major defect of it is that it can be intimidating where and how to start. The best part is that it updates instantly via the cloud so if I encode something like a grocery list on my iPad or PC, it is immediately on my S21 and there are tons of videos about how Notion has changed the professional life of others on YouTube such as Thomas Frank and Cambridge doctor Ali Abdal. I'll link their videos down below as well. I think it is horrible that Microsoft Office requires a monthly subscription on iOS. Thankfully, Apple's free pages works well enough and it converts to Microsoft Word files with no problem. I'll come up with a separate video on the best productivity apps on iPad. The Magic Keyboard, especially the 2021 version, seems grossly overpriced which it truly is. It is nevertheless a necessary evil which should be obtained in order to get the full magic and enjoyment out of all recent iPads which support it. Gone are the medieval ages in which a keyboard and mouse needs to be paired via Bluetooth. Instead, it is quite literally as simple as angling it in until you hear the satisfying of metal on metal. It is dummy-proof, fast and requires no extra step that needs to be done in the settings area. It isn't however just a keyboard, it's also a protective case cover when it isn't in use and it turns into an extremely versatile monitor stand. Being able to adjust the tilt of the screen allows me to use the iPad Pro in numerous settings whether that would be typing on a desk, a sofa, watching Apple TV on my stomach or dare I say it using it in the bathroom. The Magic Keyboard adds a lot of value even when it isn't acting as a keyboard. Finally, the point of the accessory was never to shackle the iPad Pro to it. The fact that you can just take it out at will so that you can remind yourself of the convenience and also the danger of holding a thin slate of metal is an extremely satisfying experience. Especially when you want to relax on the couch with a good digital book or to catch up on the news both of which are things that I tried to enjoy with my Surface Pro but ultimately couldn't because the interface required too many steps before I could even get to the news. As a PC user all my life I never understood Mac users who would rave on about how productive it is using a Magic Trackpad. To me it just looked like more work because you were constantly using more fingers than necessary to execute one task which would only require one finger on a traditional mouse on a PC. I was honestly just going to ignore the gestures option altogether and just attach a third-party mouse but since day one I have been hooked on being able to switch between apps seamlessly through swiping left to right or swiping upwards in order to head back to the home screen with three fingers. I realized now that I wasn't willing to give gestures a chance because of a deep rooted prejudice in which I believe that for a system to be truly productive it must have the same kind of mouse functionality as that of Windows. And just because iOS looks and acts different from Windows doesn't mean that it is inferior to it on a productivity level. This is coming from someone who has hated using laptop trackpads all his life. After changing my command key to the globe button I felt right at home with similar Windows shortcuts like Ctrl plus C, Ctrl plus V to copy and paste, and Ctrl F to bring up the search bar. To be honest if you are on a tight budget you should really consider just getting the 2020 iPad Pro especially since you can accomplish most of the things that you want to do with the M1 there for the moment. However, I opted to go big because of the gaming PC builder in me who always whispers the need to future-proof my setup by investing in the best now so that it lasts me longer in the future. The M1 iPad Pro stands out from the previous new iPads not because it is obviously better since it is the most recent iteration but because of how large a quantum leap forward it has achieved with its new processor. It quite literally has the same processing power of Apple's desktop Mac and their most powerful MacBook Pro. Unfortunately, as we saw from WWDC a lot of this power will continue to remain untapped. But when Apple released iOS 13 back in 2019 it empowered older versions like the 2014 iPad Air 2 to have access to external storage, a sort of mini quantum leap for that iPad then. In short, I'm willing to take the gamble that we should expect Apple to release an update which will make use of the M1's power within the next 12 months. Besides, if you are in need of a laptop replacement and the programs you need already exist on the iPad then I highly recommend you just make the plunge and go for the M1 iPad already. The M1 iPad lacks competition. If you're looking for a tablet which is just as versatile when it comes to removing its keyboard, a responsive stainless and a powerful CPU then the only real contenders which come to mind are the Galaxy Tab S7 Plus and the Microsoft Surface Pro 7. I however swore I would never buy a Microsoft laptop or tablet again due to the three times that I needed to replace my Surface Pro 4. The first two times due to it being unable to boot up and the last one had a defective screen which shows up on and off. This defect is so well documented that Microsoft extended their warranty policy. Unfortunately for me my screen acted up after the expiration of the extended warranty and so now I'm stuck with a laptop that has a screen which works when it feels it is up to it. The worst of all however is that after the same amount of time of owning my old iPad I never felt confident with the battery life of my Surface Pro 4. Like most laptops I have used in the past the standby time and battery drain is nothing near as close to my robust 2011 iPad and so it was a given that I was always needed to have the charger with me which plus added bulk to my bag in short my bad experience over the years with Microsoft Surface and laptops in general had convinced me to steer clear of Microsoft products and to think very hard before buying another laptop. I was originally considering getting the Galaxy Tab S7 Plus but the M1 chip benchmarks leave almost the entire competition of tablets and productivity laptops to shame and even assuming the upcoming success of the Tab S7 Plus comes out with a processor which was just as good or even slightly better than the iPads the app ecosystem of Android just isn't as attractive as in the iOS. Editing videos is very important to me. I have been doing all my editing on my gaming PC through DaVinci Resolve so far but I've heard raves of people editing great content using LumaFusion on just their iPad Pros. I haven't done it myself but these guys have and their experience was enough to convince me that the M1 iPad Pro has the power I need for what I needed to do which is editing videos on the go and having a reliable piece of hardware I can write short scripts and short stories with. In conclusion if you have been waiting for a sign for when the best time to buy an iPad Pro which is more productive then this is probably the best time since the inception of the iPad to get it. If you are a Windows and Android user like me you'll be happy with the subtle increase in freedom yet still be occasionally flabbergasted at some backward missing features. Nevertheless the M1 iPad Pro is just the latest iteration of a device with a consistent history of power, reliability and a long life. We want to give an extremely special shout out to our top fans who helped pay for this new teleprompter. Liam Magnaje, Ian Meru, Richard Ongkinko, ITX Addict, John Rubinochia and Christian Aspinosa. Thanks a lot guys this is going to make producing content a lot faster. Stay safe everyone.