 Welcome everybody. Good morning. Good morning, KubeCon. Good morning, everyone. Today, we are here at OpenShift Coffee Break. Our morning shows in EMEA. Today, with a special edition for KubeCon Europe, we're kind of warming up KubeCon. And today, I'm very glad to have our super guest, which is Siamak, Saden Giafar is the PM for OpenShift Github and Pipelines. And I'm always together with my friend Tero here at OpenShift TV. So I'm gonna just give the word to Siamak just to kick off this early morning show, right? Let's have coffee first. Yeah, thanks. That's all. I have a coffee here as well. Good morning to you as well. And I appreciate having me here. I'm like I said, I'm a PM for like an OpenShift team at Red Hat. I look after CI, CD, areas, getups, one of them. And really happy to be like one of the starting shows of KubeCon. Exciting. It's a very different KubeCon than what we used to, but never the less excited. Yeah. So and today we have a full agenda here of OpenShift TV. We're kind of kicking off this full agenda. Let's say Githubs today is really the main topic and we will have this discussion today this morning. And then we will have an office hour, Githubs office hour in the afternoon, set afternoon. Always with Siamak and Giafar. And then we will have another office hours for OpenShift. But during the show we will give you also details about it. So today, Tero, we would like to wrap up also with Siamak. The great Githubs con that was streamed on Monday as a co-located zero day event at KubeCon. Do you have any feedback, Siamak? I heard there were 1000 people attend. That's a great number. Yeah. So it was really exciting to see. This is, I know like we talked to a lot of customers at Red Hat about the problems they have around Kubernetes, around managing OpenShift, deploying applications and Githubs has become an area of interest for many of our customers. But it's really interesting to see that the wider landscape of Kubernetes user base and community also reflects that. That there is a huge amount of interest in Githubs, not as something that is hyped really because it has been, it's nothing new. It has been around for a long time. But a lot of, like mines at different teams, different organizations, community had come to the same conclusion. And I was really happy to see the initiative taken by viewpoints around Githubs working group and the community that is formed there in CNCF. So we were like through to be part of that and see really all this excitement about coming up with best practices, sharing knowledge about like everyone is addressing more or less the same problems with Githubs to be able to share this knowledge and culmination of that in a conference at KubeCon. I think that was, for me personally, that was really exciting to see. And the level of participation was like beyond my expectations, obviously. KubeCon has this nature of a lot of different, more focused, like many conferences are really competing for attention. And it's interesting to see that so many people are dealing with the same challenge that Githubs talks about, trying to put as the high level of like the huge participation in this conference. Cool, cool. So there were lots of also of interesting talk. This was co-organized by Red Hat and WeaveWorks, right? It was a kind of a collaboration on that. That's correct, yeah. So the background is that WeaveWorks is really the folks behind by calling the word get up. So they have done an amazing work and making Githubs a known practice on their particular term. The practices in Githubs, as you can imagine, like most things in software and IT infrastructure are not completely new. Especially like I know both you and Tero personally and coming from like being more acquainted with developed software development and especially you, a lot of focus on software architecture and things like that. Practices in it are not new, really. They're known to a lot of us when you look closer at Githubs. But WeaveWorks had this great effort on bringing a name to the practice and more concrete to define what that practice means. And so they are like, I see them as one of the really influential actor within the Githubs space. And Red Hat, like we about seven, eight months ago started investing heavily in RPCD because it solved the Githubs problem like really well for a lot of our customers on Kubernetes. And so it felt like a really great chemistry between the two vendors to come together. Spend time to organize this conference. This is not really for us, this is for the larger community, but at least take the initiative to organize this. And that was really a fantastic journey. We have had discussions with WeaveWorks before where this was the first time that we together coordinated events. And I'm really pleased with the outcome and hoping that more of this is going to come over the following years as well. Awesome, awesome. And this is, I've read and I also heard that it's part of the Githubs working group, right? There's a working group inside the SIG, inside the structure of CNCF working group. This is interesting. Can you explain a little bit how it works in this part? Yes, exactly. So this was essentially the first conference or mini conference that represents that working group, the Githubs working group. The reason that Githubs working group was formed is to create a vendor neutral community to discuss, share ideas and come up with, I wanted to voice it to say best practices or rather guidelines of how these practices could be used, how do they need to change so that they can apply to a wide array of use cases that different organizations and different teams have. So without that, even before Githubs working group, you could see already a lot of vendors talk about Githubs and Githubs practices, but what was missing is that the discussion very quickly gets focused on a particular technology that one vendor has. So you could see this in Red Hat as well. We've worked in CodeFresh and others as well that when we talk about Githubs, it's a particular perhaps flavor of it that is a little more adjusted to the products that Red Hat offers or products that we've worked on. And that is useful for users of that product, but perhaps not as much accessible if you're using different types of products. There are a lot of different Kubernetes flavors also out there and there are nuances there. So the idea was to form this as a place that we talk about these practices, regardless of what technology is being used. And when this idea was raised, we saw a huge interest from a lot of vendors that have been active in the CI CD and Githubs space and a lot of names like the need of the form that that we took as a great sign that there is like sometimes when new concepts and new technologies or new movements become popular, you see vendors sometimes become very protective. They want to protect their territory and become the definition of that space and lead that space for their customers and you sometimes end up in multiple actors dividing really that space. You could see that in the beginning days of Kubernetes as well. Kubernetes was one container platform or container orchestration among others and every vendor was trying to push that forward and make that best for all the use cases. Eventually out of merits of Kubernetes that became the de facto, not because everyone in the beginning agreed. When it comes to the Githubs working group, it was like really pleasant to see that that territory seeking is not happening, that everyone is on board to come up with like collaborating, putting their own individual interests inside and collaborate on practices that would benefits everyone and every organization that would be a practitioner of Githubs. So that's how it was formed and like out of that there are actually some really interesting initiatives are being born. One of them is that was announced actually at the Githubs Kubernetes bill is the open Githubs project, which is a sandbox project in CNCF and the aim of that is to come up with the principles of Githubs. So we have a common way of talking about it. We come on set of practices. We conceptually know what Githubs is and all of us more or less think about the same with their nuances that are different. For example, some customers when they say Githubs it is they're almost religious about it that every change in a Github repository needs to automatically go into the production. So as soon as it is in Github it automatically gets deployed in Github and if you don't have that, they might like say that you're not really doing Githubs. There is that breakage there that Github is not in sync with your production environment. There are customers that are that this would be extremely scary for them that once you have something in Github that goes immediately in production. There need to be a lot of checks in place that prove all very rigid process of rolling out something to production because of regulation or other aspects. There are good reasons for that, but even that could be polarizing that are we doing Githubs or not doing Githubs and we're all technology. So, although in the grand scheme of work and application delivery, maybe this is not that significant, but it does become a polarizing issue for a lot of us and the discussions of what is part of the practice or not. So the aim of opening Githubs is to through collaboration come up with this well-defined principles. This is what we think is practice of Githubs. This is what all of us try to adhere to and if you're a practitioner, this is how this is what you follow to get benefits of Githubs. If you're a vendor, if you're building solutions, tooling, if you're a community project, building things around Githubs, these are the areas to focus on. These are the challenges to address for the user, for the organization, Githubs and Githubs. So I'm really excited about a working group and the work that is coming out of it. And this has been such a short time, like really since it was formed, it was a couple of months back and we already had Githubs con. So it's going to be an exciting year to watch and what else we will do through this working group. Wow, it's awesome. First, the collaboration across vendors. As you say, it's not a competition, it's a collaboration in the industry. And this brings the open source, driving through the open source this process. Githubs is also a question that I have, because as you mentioned, there is that that can be some ambiguity. So how can we position Githubs inside the DevOps methodology and how Githubs talk with the CI CD part? Or is Githubs part of the CI CD? This is interesting to understand. Sure. So that's definitely how I see it at least. That DevOps is really that the broader and compassing movements talking about collaboration. Like DevOps is not a specific thing. There is no checklist that is saying, if you're doing this and you have DevOps, if you don't, you don't have DevOps. I think it's always when you see DevOps teams separate from the rest of the organization or these types of approaches to DevOps, you usually see a lot of reactions to it. Because DevOps is that an encompassing movement with huge focus on the people part and process part. So people and culture is really the main ingredient that makes a whole difference when an organization is adopting DevOps practices. And then there is the process and workflow of doing things. Then there are technologies supporting this. But if you don't have the people part, if you don't focus on the culture bit, there is only so much that it can't do. DevOps is really highlighted this way of thinking that this is a cultural change, the way that you collaborate between various roles in software delivery. And the name is a little misleading, like when a couple of years back when DevOps was at the peak of its high, the height of its peak. You could see always this blogs or slides like putting DevOps on one side, ITOps on the other side, throwing stuff. But now that the height is behind us and the more the tire has hit the asphalt and a lot of organizations are like facing the reality of adopting DevOps, and it's recognized that that culture changes, of course, beyond the Dev and ITOps is about every role that is involved in software delivery. There are not only these two groups, there are many, many teams that are involved when a piece of code ends up at a customer in a production environment. And it's about a collaborative way of working with all of those. What DevOps was not is or is not is that descriptive concrete way of achieving that. So it's about values, it's about culture change, it's about process change. It doesn't give you, this is the specific way of you do DevOps. And if you're not doing this, you're not doing DevOps. When you look at organizations that are adopting DevOps and adoption is really high above like 70% and you look at different surveys, they all have different ways. The actual workflows and the ways and organization structure, all are a lot of them are unique to themselves, but they realize the values of DevOps. So that's how I define DevOps. GitOps is a concrete way for the process part of DevOps. So GitOps, the three areas of DevOps is that the people and culture is the process, the technology. GitOps doesn't do anything for, doesn't do much really about the culture. It doesn't change the organization structure. It doesn't like to really make it any more collaborative if the organization is not really designed that way. But it focuses on what kind of cross concrete process can be used to realize some of those values of DevOps. And since it already names Git, it talks a little bit about the technology, but the focus is really on the workflow and process and a lot less on the culture change and a lot less on the tooling. That's a way of, it's one of the ways that you realize the process part of DevOps. And it is related to CIC, like you mentioned. So continuous integration, continuous deployment, continuous delivery, those were all like practices advocated by DevOps with really under them, automation umbrella. So that like one of the practices of DevOps that you want to automate delivery of application infrastructure to a great extent. And CI and CD are one way of like performing those kind of automation. Again, it's at the like high level of concrete. GitOps is really one, it goes under CI CD that is a very concrete workflow of how do I, how do I perform. CI CD, because CI CD itself could be done in a lot of ways, but it provides a very concrete process of how, how one might do CI CD. Cool. Thanks for this explanation is very accurate, very precise. And I also were wondering, you know, that is a great DevOps. No. So that was the best. You were a great DevOps. I don't know what you're doing now, but you were, you are a great DevOps. So I would like to know, so from you, what do you think about the impact of these GitOps technology and approach through with that can be done with open shift to customers that will adopt this. This is not only the technology like CMAC say it's also a methodology. And it's part of the DevOps. So what do you think about it? That's a good question. Actually, one comment to the CMACs about the standards that I built. There are a lot of similarities that happened with the service mesh. So, like, there was several different services and then there was one leading contributor that like it was like started building some standardization, because like CMAC said that there might be battle of the like battleground that which is the leading way to do something. It's a good approach. But about the DevOps and we have seen like like CMAC said well that GitOps is a more it's not about that much about culture. It's a concrete way of describing how what what is happening. And it is something concrete. We have seen these different adoptions like some let's say some some companies are still using VMs. They are still in adoption of containers and then at the same time they live through the DevOps hype. And now like CMAC said there is no hype anymore. It's just it's just there same happened with Scrum. No one mentioned Scrum Masters or Scrum anymore. It's just there in the in the standard way of working. But I totally agree 100% with CMAC that DevOps is a cultural way and GitOps is a way of doing. And I think that it is easier for customers to adopt GitOps because they can see the value. It is something concrete. I have said to customers that because they ask about why what is this GitOps how do I do how do I how can I do it? What is there for me? And how do I need to have tooling? What is the best tool? I said that easiest way just put your code to Git and run it through Git. That's the simpler way of GitOps. So you don't have to have automation like CMAC said that it is scary that every commit, every boost goes to production. I would say that not many companies are ready for that. Not many companies are ready for deploying once a day. Not many companies are ready for deploying once a month. So having kind of GitOps way that there's this hard, I would say, religion. It's the same as there was in Scrum and DevOps that this is the only way of doing some use Git flow, some use different ways of using the Git. And like you can start with really small steps like using Git as the single source of truth. And it can be easy as Qubes CTL apply minus F. That's your GitOps. The GitOps automation tool is that developer ops person, but that's the easiest way. And that is kind of it doesn't have to be automatic. It can be manual, but as long as the flow is correct, then it's easier to get from there. And I think that this is a good thing that it's really easy to adopt. If you think about that CIO in a company has a target that you need to adopt DevOps. How do you measure that you have been adopted DevOps? You can't because it's a way of working. Every company has its own definition of DevOps, but with GitOps it's easier because you can more strictly define the targets that when we have achieved GitOps way of doing like we automate deployments or we run everything through Git. So I think that in these ways, the world is ready from the tooling point of view. There is flux, there is Argo CD, all the major Git providers are providing the GitOps tooling in there like GitHub, GitLab, BitPocket, all those have their tooling already. So it's just missing the part of you just to start using it. So I think that it makes really easy to start using GitOps and there is real value in there. Like famous Cia Max said in cloud native development slide that you cannot do proper containers and DevOps without automation. The automation needs to be there and the GitOps is a good way to provide the automation. Really long answer to your question. That's actually a great point. I wanted to mention that as well, but this is a question that you see asked a lot about DevOps. Where do we start from? Because it's so obscure, it's a set of values and practices not very concrete or descriptive. There is no single answer to that. One organization or team needs to start from. But you don't see that question get asked about GitOps because it's extremely descriptive. It's a very defined flow and how things to happen. So I do agree that it's much easier for adoption because a lot of those practices are predefined in GitOps and makes it much clearer for teams or organization what they need to do if they want to move toward that. And the other thing I picked up when Tara was talking is that this is exactly the value of GitOps. When teams start looking at GitOps practices, they notice that they are doing a lot of that already. Because a lot of what you don't want into that, there are like a majority of customers who talk to teams, talk to them, they are using Git. I wanted to say or some sort of version control, but even the some sort of version control is gradually diminishing and majority using Git in some format. It doesn't matter what they are doing, if they are creating, if they're using Terraform for provisioning infrastructure on Amazon or if they're using Ansible or doing something else, whatever they're doing, they are usually putting all of that in Git. They are versioning that they are using the pull request workflow. And this is about the operation part when it comes to the app dev that's the entire flow is really what has been used forever. So that makes it really accessible that it's not about really shaking the organization up with the whole new sets of technologies of working, but we were like picking things that people have been doing already and put them together on their like a concise practice on how they relate to each other. So I think that makes it extremely accessible to a lot of things. It makes it really simple for organizations to start with. And also one addition to that is that when Kubernetes started to get traction, the only thing that was treated as code was the actual source code. And now the Kubernetes manifest, actually, people see those also as source code. And like Siamak said, everything is already in Git. The way how they are just deployed may be a different. There is a lot of young files like some said that I don't know who it was that DevOps is equals to young files. That is kind of true because what you know if we take the standard you run Kubernetes, you run containers. And I can say the third hybrid cloud so that buzzword. But what you actually is common to all those young files. If you say Kubernetes native, it's a young file. So that is even though it's a text file, it's still a code. And when you treat it as a code, you are basically doing GitOps because it code is in the repository. It can be SVN ops. It can be CVS ops. It doesn't matter, but GitOps is kind of more trending. Yeah, yeah, I agree. I think as you were mentioning, most of the people were doing kind of GitOps before GitOps became a thing like having a manifest on Git. Also part of the infrastructure as a code part of it, right? Having everything in Git, but there wasn't this controller. So maybe we can talk about also about the open source project we are using in OpenShift with GitOps, which is argocity. In this case, there is a controller that keep everything in sync. So let's say we were kind of doing that manually, putting everything in Git and doing a kubectl apply or OC apply. Now we have also a tool, a controller that help doing that. And maybe we can also introduce that. I was looking in the while in the chat with some people in the chat that are waking up. Hello, Sebi. Hello, Dario. Dario is a friend which is having also talked to a kubectl. Hello everyone. There's one asking about Doge. I think it's another thing, but I don't know. Let's say GitOps and crypto maybe something like that. But yeah, I would like also now to interact and please use the chat to do any question about GitOps. We have today, this one is Siamac. So catch the opportunity to ask to him everything about GitOps, but that's also the strategy I would like to hear from you, Siamac. Also, what is our direction in OpenShift towards GitOps? We can, of course, we introduced and anticipated the talk about ARGO CD. So what is the strategy of GitOps? And I know there is a GitOps operator in OpenShift. What is OpenShift strategy for GitOps? So yeah, an OpenShift VR, the way we see the mode of operating Kubernetes and delivering application on it is that GitOps fits extremely well to that environment. And because of it, we are investing heavily in GitOps with CICs. There are two prominent add-ons on OpenShift that support this way of working. There's OpenShift pipelines based on the upstream Tecton project. And there is OpenShift GitOps that delivers ARGO CD on the platform for that controller, the GitOps loop that you were discussing. Tecton has its own merit, the CI part. I mean, the GitOps, we don't talk about CI much. It's an extremely interesting area and a lot of solutions out there. But one of the problems we had seen is that it's difficult to really, there is always a gap between the pipelines that do the CI for your application and the Kubernetes environment. And Tecton focuses on really building on top of Kubernetes constructs. And you define your pipelines in form of pods and config map and secrets and constructs that are Kubernetes native. So it makes it really simple to have CI that executes decentralized Kubernetes. And OpenShift GitOps, you have ARGO CD that focuses on using that. So even though we say CD, I think this is also a change that has recently happened. That CD before like four years, five years ago within DevOps, CD was used to always CI and CD were used to get it to refer to the entire delivery process. More recently, when we talk about CD, we mean the deployment phase. How do you roll out a deployment of application after it's the images, the applications released through the CI process? How do you roll it out to all the environments that it needs to run on? So that's why we focus on CD. And OpenShift GitOps focuses on this particular use case. And both of them are generally available now, like we announced at GitOpsCon. They're extremely excited about that piece as well. So we do see that as the general direction of what makes it simple to operate Kubernetes. This goes in handy now, like Kubernetes in general. This is what I want to get out to. If you take a step back, Kubernetes has been a huge enabler first for DevOps, like containers and Kubernetes, and now for GitOps. For DevOps, because of the level of automation that Kubernetes provided, you don't need Kubernetes to do CI CD. But with Kubernetes, it becomes extremely simple because it's super simple to provision a new instance of your application in your QE, versus doing the same on a virtual machine on your hypervisor might not be as simple. So that really pushed adoption of DevOps. But especially when it comes to GitOps, the reason I think this goes hand in hand with Kubernetes is that Kubernetes really made this controller pattern very well known and familiar. Like could the controller pattern that Kubernetes implements, or it's a core of how Kubernetes operates, was not invented by Kubernetes, but it's an extremely useful way to look at driving operation. You declare what you expect, what you want. And in form of YAML or JSON, you put it in its CD, and there are controllers that go and do the work to make it happen. Instead of you saying, first do this, then do that, then do this, then add memory, then add storage, and then I have what I need. You just say, I need something that has this much memory, does this, looks like this and that. And you hand it over to the controller, the controller goes and does whatever it needs to do to make that happen, and gives you what you had described. So this way of this mode of thinking really became extremely familiar because of Kubernetes, is exactly what GitOps is really, except that we are saying that expand that to everything about your application and infrastructure, not just what you expect from Kubernetes, not just those manifest. And in the case of Kubernetes, you put those things in its CD, in case of GitOps, you put them in Git, there is something missing in the middle, as the controller you were mentioning. So somebody got to look at this Git repo and do the same thing that Kubernetes does for its CD. Kubernetes console looks at its CD, and whatever it described there tries to bring the cluster up to that state. So in GitOps, you need to do someone to do this for your Git repository, and there are a lot of technologies that do this. Red Hat in general, if you look at how Red Hat operates, Red Hat brings really like open source projects that have a lot of potential, and they are very well built, and they have a very democratic community around them, with it community, makes them consumable for enterprise customers. Like that's what we do across everything, like any piece of software you look at Red Hat. So we started looking at the community around GitOps and what technology exists, and our CD sticks out as an extremely popular controller for GitOps, started by Intuit, or started by Intuit's Acquire. Intuit for like in Europe, maybe they're like known less, they have different type of tax applications and cloud-based services like TurboTax and things like that. So in North America, they're extremely popular, and they run hundreds of Kubernetes instances, and they're using Argos CD, they built Argos CD as a way to operate all these clusters. So it was an extremely battle-tested piece of software for the GitOps method used by the organization who created it. So it showed a lot of potential, and also we saw an extremely active community around it. When you look at the Argos CD project, there are more than 100 organizations that are publicly speaking about using Argos CD. There's a list on GitHub you could look at. So we saw a lot of puzzle pieces come into the right place as a project that is extremely successful, extremely well-adopted, and customers on Kubernetes and OpenShift could benefit heavily from this. So we started talking to Intuit and formed a partnership to invest more in it, and then bring it as a supported GitOps solution on top of OpenShift. And there are other technologies available, do the same, like ReWorks has as flocks and real-life technology. Those are also available as community software on OpenShift. But the value of Argos CD was that the community was extremely well-designed and active, and solves a problem extremely well, very native to Kubernetes, and fits really well with the rest of OpenShift and other technologies that work with it. So that was the initiation of our journey. And fast forward a couple of months is we have both of those pieces of software taken on Argos CD as the foundation of continuous integration and continuous delivery on OpenShift. I'm extremely happy about that. And what we're looking forward is we want to bring these technologies a lot more into the ecosystem of OpenShift. So OpenShift is a platform. It's not a single piece of software. It's a platform with a lot of, with an ecosystem of software from Red Hat, products from Red Hat, and products from Red Hat partners that run on it. So we want to make sure that these two pieces are really well integrated and can take advantage of other capabilities that come through these other pieces of software on OpenShift platform. As an example, the Red Hat has acquired recently StackRocks, and it is released as Red Hat Advanced Cluster Security, ACS, which is like a really nice solution focused on platform security, continuous security. You can get compliance, make sure that your platform is NIST compliance, for example, or HEPA compliant, and it can scan images and configuration and create a really nice compliance report and allow you to fix it. So we want to make sure, for example, that we can use that as to enable DevSecOps use cases within OpenShift pipeline, within OpenShift GitOps and tie that together as a CI-CD flow that not only it is a way approach to implementing GitOps, but also it has security built-in, it has security checks and security flows built-in into that process. There is, for example, another product on OpenShift, Red Hat Advanced Cluster Manager, which is really well designed for cluster lifecycle managers. You want to provision a cluster on Amazon or Azure or VMware or different platforms. You want to manage your fleet of clusters as a group and look at the workloads, look at different aspects of it, and you're looking at a very tight integration with Argo CD there so that in Argo CD, you can sync a particular Git repo to a set of your clusters that are defined in ACM, for example, based on a set of labels. We can say that in Argo CD and Argo CD, usually you say this Git repo needs to sync to that cluster, but we want to make it more dynamic through ACM, say right now, I know that this repo contains my application, but right now I don't know which clusters are the production clusters for this application. I know it because we have a very dynamic infrastructure and the production clusters today might be these 10 clusters and through two weeks later, there might be different 10 clusters. There are short-lived clusters, so I want Argo CD to, at the time that you're deploying the application to somehow figure out what are the production clusters at that point and sync the application to those clusters. So we are looking at tight integration with ACM because ACM manages that fleet of clusters for the customers and it knows which clusters are production clusters at that point, so Argo CD can talk to ACM, retrieve the list of clusters and start syncing to those as an example. So we are looking to integrate in a lot more and more these two technologies into ecosystem of OpenShift and other pieces of software from Red Hat and partners that run on OpenShift and make it a really seamless experience for customers to want to start with a GitOps workflow on OpenShift and be able to get a lot of value across the entire ecosystem of products and add-ons that are available on OpenShift. Wow, Seema, this is awesome and I'm sure also Tero is very excited about this news about integration between ACM, which is the multi-cloud, multi-cluster management. That's my new favorite term, hybrid cloud, multi-cluster DevSecOps. I think that's my new favorite. You sold it very good. Yeah, but now we have been talking about DevOps, GitOps, deploying applications, but what Seema can take on actually using GitOps to manage the OpenShift, basically, GitOps is just containers running everything you need to run your application and production. What's your take on using GitOps to maintain the platform, not just applications? That's a great question. Coordinated, like we discussed, it's made infrastructure really declarative, but configuration of Kubernetes itself is not necessarily bad declarative. When you look at OpenShift, OpenShift adds a lot of peripheral components to Kubernetes to make it useful. If you want to use Kubernetes, you need a registry, you need Ingress controller, you need all these pieces around this so that you can actually deploy an application and use it. We spent a great deal of effort in OpenShift 4 to make sure that configuration of platform itself is also declarative, so that if you want to configure a particular Azure AD as the auth provider for OpenShift, for example, you have to go run commands, say, add this and that, and that, and at the end, you have Azure AD as the item to provider of OpenShift. Rather than that, you can describe that in YAML, the beloved, hated YAML, and you apply that to the cluster and cluster configures itself based on that description, that declarative description of the configuration. And that has been an extreme effort. We spent one and a half year almost on making the entire platform configuration declared in this manner. The advantage of the fruit that we get, one of the fruits of that effort is that you could point, you could put the entire configuration of the platform in a directory from YAML and run a kubectl apply, and the cluster comes to that baseline configuration that you specifically wanted and change all the knobs that you would like. And if you're running a lot of clusters, you could just use the GitOps flow similarly to automatically sync all those changes to the clusters that are connected to V3. So we see almost every customer on OpenShift that we see uses Argo CD. They start with this use case that they are using the GitOps workflow for configuring the cluster itself. So if they want, there's usually a platform owner, a platform group that manages the OpenShift cluster for other teams within the organizations. And they own a Git repository that contains a configuration of the platform. And if other teams need a change, they could also, they could even send a pull request. They would ask for a change themselves, modify the config, send the PR to that repo. The owner of the repo really used that. And for example, they want to enable a particular function in the internal image registry of OpenShift. So they send the PR that contains that change in that config YAML of registry. The platform owner team really used that. They merged it. As soon as it's merged, Argo CD picks up that change and sync it to all the clusters that the config relates to. And automatically it's applied there. So the platform owners, they have like the advantage of this way is that the wider organization has a way to request changes. It's not ticket based. You actually request, you send the change that you want. But at the same time, the platform owners have a gate and they are the gatekeeper. They have an opportunity to review, discuss, maybe reach back to the request there. Why do you need this? There are other ways to handle it. And once there is agreement, apply that and rolling it out to the cluster. And with that, like the advantage of this is that the visibility that you get on those changes, right? Every change that goes into those clusters, you can always come back into the history of the Git repo and see what conversations happen. And this is actually like, it's really important. I wanted to mention about majoring. You talked about majoring, like how much DevOps or GitOps we're doing. That's extremely actually important point that why do we do all of this? Why would we even start with GitOps? Sure, it's a little cool now and the automation hails. But what we really want to get to is a set of metrics that are important for the organization. So you hear a lot, like within DevOps, there are a common set of metrics that we talk about, like the lead time for rolling out a change. How long it takes for the change to go into production? Or how long, once we have a failure, how long it takes to restore our state to a function like restore? Like the mean time to restoring the service or recovering the service from the failure. And the GitOps workflow that we talked about for rolling out configuration to the cluster. So let's say there is a problem in the ingress control. The problem with the ingress control is not functioning the way you expected. The way to, like the GitOps workflow, it's a huge help to be able to connect that when was the, what are the list of changes that are applied to the ingress control controller. In the last, like over that time window from when it was working fine till now it's not working fine anymore. So let's trace that back to what was the specific changing Git that was causing this change on the cluster? Who issued it? Who reviewed it? What discussions were happening on it? What was the state before that? So all of that information you get immediately in case of Argo CD, we really a click from the SHA idea of the commit back to the Git repo and what change. We had extremely like provides a lot of information, useful information to reduce the time to recover it because you get all that contextual information at one place for you to be able to analyze and figure out what was wrong and go correct the situation. Awesome. Helpful for like improving those kind of metrics within the organization. The most important for the auditing part, right? Many users ask about what about the auditing, who makes what, how to roll back, how to roll forward. So this is very cool. And also another question I would like to know from you is there will be more integration between OpenShift web console and Argo or GitOps. At the moment, you can install OpenShift GitOps operator, you have Argo CD running. Will there be like pipeline, like tecton with more integration in OpenShift console? What is the future for this integration? Yes. So that's a great question. So like one of the good thing about Argo CD that it comes to the really nice dashboard that gives you a lot of like contextual information on what Argo CD is doing and how it's syncing and what's the status right now. So we are working on is to grab this information from Argo CD, combining the information we have about the runtime of the application on OpenShift, combining the information we get from Git, and come up with dashboards that show more the life cycle of application from the application point of view. So in Argo CD dashboard, you see the entire fleet of clusters and applications from Argo CD point of view. In OpenShift, you're working on views that kind of trim down that information to a single application view. So we have an application called payroll and it has four different environments. There is dev, there is stage and acceptance testing and prod. And I can see how application flows between these environment. And I can see that it was deployed on the stage. And for example, what was the change? What's the status of application on that environment? And the history of this flow from a single application perspective. So an application dashboard, if you will. Definitely working on those kind of areas to augment what you have already in the Argo CD dashboard with other mashup of information that you can't get by just looking at Git or just looking at Argo CD or just looking at OpenShift. Awesome. Thanks for this update on this integration, which is very cool to have all these tools integrated in OpenShift. Also with OpenShift, we have more and more tool in OpenShift integrated with OpenShift authentication. So there's single control plane, right? We're seeing auditing place where you can track everything. So this is a very cool. And we have somebody in the, let's say, let's see the chat. So somebody brought it's own coffee. Welcome. This is an OpenShift coffee bread. We enjoy and coffee with you and talking about such awesome tech discussion, right? And yeah, I shared also in the chat the Cata Coda learning path that we just published on learn, OpenShift.com. So all the people can start trying OpenShift, GitOps operator, trying user using Argo CD and doing everything you said, right? Going implementing the tool, looking at the dashboard. Yeah. So this could be also useful. And we shared also this lab in GitOps.com. And we would like to hear from you any feedback about that. And this is not the only place where to start with GitOps, right? We have more and more tutorial guide session coming. Yeah, definitely. Like the Cata Coda one, the one you shared, what I like about that is that you don't have to, you don't really need anything. You just need a browser, right? That's all you need. You don't have to get into the maturity of like running an OpenShift instance locally or getting a cluster and so on. It's not that difficult to do that, but with Cata Coda you're just having a browser. So definitely recommend to start with that. And even if you can get creative, like there are multiple tutorials and guides that you see in the blog post on OpenShift blog and Red Hat developer. And even outside on Medium and Elsevier on Argo CD and Tecton, you could actually use the Cata Coda environment to run a lot of those as well if you don't want an OpenShift, if you don't have access to an OpenShift environment right now. Yeah, a lot of content comes out in the coming weeks on OpenShift from Red Hat developer blog, but also keep an eye on the Argo CD content. The community is extremely active, so we see a lot of content popping up about different ways to use different parts of Argo CD and Tecton. I can tell like both of these projects grow like really fast, both deep and on the breadth there are new areas that are coming along in those and we're happy to see there's so much like guides and instructions coming also alongside it to advise users how to use different part of it. Awesome, awesome. And we have a lot of content. Yeah, this is a big ask to all the listeners, if you do something cool with KIDOPS, please share it. You do work in the companies, you might have to do top secret things, but I hope that you can share something. Like write a blog post, write a Twitter tweet, LinkedIn, something that, what are you doing with KIDOPS, what are you doing with Argo CD, so that everybody else knows that what cool things can be done. Even though it's top secret stuff, you can, the baseline you can, you can share. Sharing is scary as we say in Red Hat, so please share what you do. And yeah, it was a pleasure. It's always a pleasure with Siamak, because the broad knowlets about the ways of working around DevOps, KIDOPS pipeline, so it's a, it's a, it was a pleasant, pleasant chat with you. Thank you. It was a pleasure for me. I really appreciated having me here. Like, it could call like early in the morning for the pandemic and people don't have to get off to go to work. It was, it was really fun talking to both of you. It was a pleasure, Siamak. Actually, Tero, we learned so much this morning. We should invite Siamak each, each episode. So we will learn more about KIDOPS pipeline. It was a very, very cool discussion. Thanks, Siamak, for joining us. And before closing folks, I need to have some reminder. So first I would like to share in the chat that we have the DevNation deep dive. So those are kind of vertical workshop to a certain technology. And we will, we have also one ARGO CD deep dive. So please register to the Red Hat developer and stay tuned because we will publish more and more deep dives also about about KIDOPS. And I want also to share also the agenda for today because today at KubeCon Red Hat is present at KubeCon. And we will have our agenda and don't miss, don't miss Clayton Coleman and 1045 a.m. says time talking about Kubernetes of the control plane for the hybrid cloud on the keynote session. Very, very interesting, cool session. And before closing, I would like to remind you our schedule that we have today at OpenShiftTV. If you go to the calendar today, we have the office hour about service mesh, KIDOPS office hour, together always with Siamak and Jafar, we will have the KIDOPS office hour this afternoon from 3 and 4 p.m. And then we will have another office hour for OpenShift for that set. So full day here at KubeCon. Very excited to be here at KubeCon. Very excited to have you, Siamak, today talking about KIDOPS. So I think we shared everything we had. And we can close this wonderful episode of OpenShift Coffee Break about KIDOPS. Thank you, Siamak, for joining us. It's been really a pleasure. And yeah, see you in OpenShiftTV later. This is a full agenda of today. Thank you, everyone. Bye-bye.