 Hi, welcome to our talk about GitLab and Flux. We're really excited about this. So recently, GitLab announced that they're going to be using Flux as their GitOps offering. So we're really excited. I'm Priyanka Ravi. I'm a developer experience engineer at Weaveworks. And I'm Victor Naj, a product manager at GitLab. And I've seen Priyanka's previous talk, where she spoke about the two dogs that she has. So I put my pets on there as well. We are really in sync here, OK? So I have one dog and two cats at home. And you can see that one of our cats just wants to play a pandemic with us there. And again, you can reach us on the QR code. There are a lot of sponsors, I guess. And you can reach me through these approaches. So why are you happy about this? I am really excited. So I was at a company called State Farm before this. And we were a GitLab enterprise user. And so I have always been a really big fan of GitLab. I really miss it in my everyday life. But it's really cool because it's an end-to-end tool. It does everything for you in one-stop shop. You can just basically go from just having code to all-the-way production, the image. There's so many good things. I could go on and on again about it. It deploy apps, review apps. It's great. And so when I saw this announcement, I was probably screaming, I think. My coworkers probably know. I was really, really excited about it. And I was like, yeah, I get to work with GitLab again. So I'm excited. Yeah, and I ran. We are super excited as well. Actually, I was following the Flux V2 developments since it started. And initially we decided that we want to build our own thing. Then we had to deviate from that for various reasons. And we just fabbed behind in GitOps a lot. And when we evaluated Flux V2 competitors, it was a pretty clear win that we want to take Flux for its feature sets, code quality, integration possibilities and all that stuff. And we had super, super interest in that. We worked both with the Flux open source community on the integration. Actually, what we are going to speak mostly about today is about that. But we work as well, we work on how to integrate at a higher level and then different levels as well. So it's really very exciting. And this is the top initiative in my team since the decision, actually. Three months before the decision already. I got here a little late. What's the announcement? Did you already make it? Yeah, in January 26th, I guess, the announcement is that GitLab will take Flux as the recommended GitOps solution and we are integrating it with GitLab to make it easier to use and nice to experience all together for Flux and GitLab users. Yeah. And so what does it mean actually this integration? That's what the talk is about. And as we are talking plenty of GitLab users, we heard that the deployment and even the royal management are actually not stand-on tasks, but they are part of a whole delivery pipeline. And I think a lot of talks around here about delivery pipelines and not just like, okay, let's deploy and then it's done. So it starts somewhere when you have an image that's built and it's in your container registry, it's scanned, et cetera, but there are policy gates, there are compliance requirements, sometimes there are manual processes as well, and in the end, you want to roll it out in front of your users. So I think that GitOps is an amazing approach for orchestrating the deployment part, but the whole process should handle more than that actually. And if you use cross pane or tarform provider or tarform controller, sorry, to have GitOps in the environment as well and infrastructure provisioning, you still need to solve many other issues and you likely want a pipeline, which will be one of the elements here. And this is part of the integration that we imagine and in next slides, I'm going to go a bit more deeper into each of these. So use OCI images, that's the first one. GitOps, I think, is just amazing as a concept. It simplifies many, many things for cluster configuration because it's declarative fully by using Git as a single source of truth initially. But at the same time, when you merge your changes to your main branch, it will immediately pick up the changes there and it makes it difficult to have the process that many enterprises actually want. And for many other reasons as well, when I heard from Flux maintainers and from experienced Flux users, the idea is that the industry's moving towards OCI from the Git repository itself as an intermediary layer between your repo and the cluster. Now, if you're not very familiar with this, don't get me wrong. It doesn't mean that GitOps is not GitOps. The single source of truth is Git. OCI is more as a caching layer, one extra step there, but everything that's in Git, that should be reflected in the OCI so don't add anything new there. And there are many reasons why this could be actually beneficial for you. One is that container registries were designed to serve images at scale like Git repositories. You can support a release process because you can merge it to your main branch from a single merge request to all your environments, even if you want to. And you can still build the OCI images per environment when you want it to be released in that environment. You can, it supports logic in the pipeline. You can run customize or JSON net, you just build your final manifest there. It allows for dealer pipeline as a result. You can add additional scanning in the registry as well, and you can sign the artifact and have supply chain security there. And thankfully, Flux supports OCI images, so we are very happy with that. Both, it supports both as a Git resource and, I mean, again, Git resource. Both as a manifest source or generic source and both for ham repositories. And the next item is the pipeline integration. We were asked actually to upload these slides to the schedule and if you looked at them before, this photo wasn't part of the uploaded version because I took it this morning at Brandon Burns keynote speech. This was his last slide where he actually wrote that the good approach is to have controllers and planners. And GitOps is the controller part, but we need the planner party that can orchestrate all of that. And this is what we mean by the pipeline integration as well. So we totally agree with him and that's what we want to achieve with GitLab. The idea is that we want Flux to be, to look like a job in the CI pipeline, not the CI pipeline because it's not CI anymore, but in the GitLab pipeline. It wouldn't be there, so it would still happen outside of GitLab, 100% using Flux, using GitOps. But to show it there that yes, you have your pipeline, this is one of your environments, this is now the sink is happening there, it's done. We continue the same pipeline, you can run post-deployment steps, whatever you want, end-to-end test, et cetera. You can deploy to the next one, and so on and so forth. So that's the idea here. Another thing we are already working on which is kind of less fancy, but could be very, very helpful and I think very valuable is to simplify the setup. With Flux, when I first used it, I was like, this is cool, but I had to create like five different tokens. And when I thought about it that, okay, I'm just testing it out with like two free projects, but if I have it at scale at an enterprise, then I will have hundreds times five and I rotate it regularly, so I don't want to do that. And with our previous approach, with the GitLab agent for Kubernetes, you had one token that you had to rotate and that was all. And we want to keep the agent actually, we are just adding the GitOps part from Flux there, not adding, that's not true. Giving away our part, so doping that part and using Flux together with the agent and the agent can manage these tokens. So we can keep the token management at the GitLab level, keep the authorization, authentication logic at the GitLab level, create the Kubernetes secrets, the tokens from GitLab, put it in the cluster and you just have to point Flux to those tokens and then GitLab will show you even compliance reports, it can rotate it for you and all of that. So this way you can have a central place for managing your tokens and get reports about your tokens and actually benefit from all the Flux amazingness there that requires these tokens. And at the same time, it allows as well things because here there's one weird token which is not a Kubernetes secret, but the other way around it's for GitLab to notify Flux that a thing should happen which is just a token. And basically this is something that the GitLab solution already knows. So when the code changes, we know about pipelines and we can easily even today notify our cluster site component. So we just have to tie the strings together that our cluster site component notifies Flux immediately without any token, for example. And finally, we are building a UI for Flux into GitLab as well. At KubeCon I've heard plenty of people coming to me that like we either be a UI because I can't convince the managers to pick Flux because it doesn't have a UI. And yes, there will be a UI. Actually, we demoed it back in March. The demo doesn't contain Flux in itself because it was started before the decision was made. But as you can see on this screenshot, we are actually designed it for Flux as well. There is hardly sync state if I remember well. And I hope to release it soon. And on that note, we prepared for one question that you don't have to ask, which is when does all of this thing happen? And we are working on everything that I spoke about for like two months now. Some of them even longer than that. Actually, there's one that is more recent. And if everything goes well, we will have an experimental version of the OCI and pipeline integration in a few days, actually in two weeks, May 22nd. It will be experimental, but if everything goes well, we will have it already. I think that we will have a beta version out of the automatically modified Flux when a change happened in one month from now. And the visualization, it's a huge task, but behind the feature flag, it might be out in a month as well. So it's really, these are the top items for our team. And we are pushing it very, very hard to get something out in front of you and then get your feedback on that and so we can improve it further. And before I give the floor to you to ask questions, one question, does this make you happy? If you have any questions, yeah. Yes, it makes me happy. For sure. And my, I guess, one, got my question. It just makes me so happy, I'm completely excited. Yeah, all right, well I guess I'll, oh yes, do you want beta testers? And what is your, I mean, clearly you put out beta releases, right? Or different, you know, sort of RSEs at some point. Is there kind of, because it's such a type priority for you, is there a focused initiative on gathering feedback from folks? And if so, how do you want that to happen? Very, very good question. Unfortunately, GitLab doesn't really have beta releases. So we have this very strict release schedule in the 22nd. On gitlab.com, we release more often and sooner, but even that is not that you have to sign up for getting that or anything like that. It just arrives earlier. How we gathered feedback was mostly through interviews and sharing the designs and stuff like that. The way why even mentioned that we, from the OSI and PowerPlay integration, we imagine it as an experiment because what I asked from my developers is like, just don't test it. Create it as a separate container that you can re-document it, how to run it in the pipeline, and just put it out there as quickly as we can. So that's how we try to get early feedback. Why did you choose Flux over its peers? There were several reasons for that. From the feature side, I already told this to some people here in the past days, is that I think a very rare feature of Flux as a software product is that it was written from scratch, but it has all the learnings from V-Works, from Flux V1, and that's a huge thing. When you compare the other solutions, what we have seen is that they either lack some features or you could see that they are not that new, like they have years of heritage and the code quality was not something that GitLab wanted to recommend for its users and after, get those users come to GitLab with support requests. We used previously other tools at lower level integrations and we moved away from those because of code quality and dependencies required there. Does this answer your question? So actually I have two questions. One is trying to figure out what's so special about the OCI part in this case. So is this not something that GitLab's container registry supported so far? I think it already did. It's very funny actually. It does support OCI and I had to ask our package team who manages our container registry, whether it be support OCI. And because I was like, it seems to me that we do, but it's nowhere documented. And then I asked them to please document it and now on the container registry documentation there's a line that says that we support OCI. But it's not compliant yet. We don't know if we would pass the compliance check right now or not because nobody ever run it. But so it's very close to be compliant as far as I know. So is this a custom implementation when do you use some of the open source? I think we built it on top of some open source library but I'm not 100% sure it's not my area. I think Victor also mentioned it because of the fact that Flux uses OCI as well. Flux can do OCI deployments. I think that's why he wanted to highlight that that's something cool that they can work together. It actually didn't work with, so if you use the Flux CLI to push images to the GitLab OCI registry in the container registry, it didn't work because of the custom media types that Flux used with that. And that was fixed the previous milestone, like a month ago, but we missed the deadline to get it into release post because it was reported one week before the release cutoff. And it's so high priority that the package team immediately started to work on it so that we get support to that. Okay, cool. And the second question, well, maybe it's a rather feedback question. You mentioned that GitLab would actually notify Flux about an image being pushed. And I guess that means GitLab would actually have to have access to the cluster. Yes. Is it something that has to go through the internet? Do you have some special solution for it? Because coming from an enterprise perspective, I know that that wouldn't fly for us. Yes. So what we have this GitLab agent for Kubernetes, what you can see here, it has actually two components, agent, K and cast. This is what we had even before, just Flux wasn't there. So it had a GitOps module that we are getting rid of and we want to use Flux instead. This is our long, long-term plan. Today, there are some limitations that even in the Flux side that won't allow this. But the basic idea is that you see that by direction of streaming channel between agent, K and cast, that is actually set up by agent, K. So the cluster reaches out to GitLab and you manage agent, K with AirBug, it's up to you what it's allowed to do. But after that, as it's bi-directional, actually we can reach out from GitLab to show you why. And the nice thing is with the CI that actually integrates the runners as well in GitLab. So we can reach out from GitLab runners from a CI job in a push-based fashion if you want to the cluster as well, even today. And that's pretty cool that we just combine the pull-and-push-based into a single solution and soon into a single pipeline as well. And we go around the security parts because state firm's also really highlighted by having our own on-prem. So we were using Enterprise. So because it was already deployed within our own clusters, it was more secure to add that connection. Yeah, you're not giving someone else access. So the very, very long-term thing that today is not supported yet architecturally from the flux side, even, is that what we would like to achieve is that the flux today basically reaches out to GitLab in a separate channel to retrieve, to pull the manifest. And on the long-term, we would like to use the agent, K connection for that as well because that way we can allow rate-limiting the main GitLab entry point and all of that and it would just scale better and be more stable. Okay, thank you. Does that mean that, I'm just thinking two things. One is flux already has essentially an endpoint for webhooks and that's how flux does it. You're not giving, in that realm, you're not giving your, this actually will be a question. Trust you, you're not giving the keys to your kingdom to your CI system, you're really just giving them the ability to say, hey, check it again. And they come and check and say, oh, yes, in fact, there is a change, I'm gonna pull that. Oh yeah, I know, I'm gonna do that. Oh, okay, cool. So my question based on this is, is that, I know with agent K generally, with or without the GitOps side of things can do pull and push based deployments. But when you're using it with a pull-only based system like Flux, are you seeing agent K as kind of a source controller caching layer in that way? And is it a similar thing where this push is really just kind of a ping to say, hey, check me again? Right now, yeah. So the first one is just a ping. So that's why I'm in, no, I didn't. Okay, yeah, just a ping, exactly. So that really answers the security question, I think, because you're not, in this case, there's no payload. Yeah, you're not actually accessing it. Yeah, you're not deploying anything, you're just informing someone, saying there might be a change. So go a little bit, so check a little faster than your normal reconciliation, Jeff. Makes sense. That's what we want to release in a month from now. If you have no more questions, then thank you very much and thanks for the Flux community to have Flux actually.