 We use ARGO for a couple of use cases of which one is to maintain a couple of large CI-CD clusters. And today I will be talking about using customized KRM functions to enhance ARGO-CD application deployments. So I'll be explaining how we used ARGO-CD config management plugin to do a computational transformation using a Kubernetes resource model, so KRM function. And I'll also be pitching what we could have done, namely what if ARGO-CD meets ARGO workflows to run these KRM functions as containers. The examples I'll be showing, you can find them back on our Nokia's GitHub space in the ARGO-CD KRM plugin examples repo. Okay, so first the basics. Config management plugins in ARGO-CD. So ARGO-CD comes with a set of built-in tools, but what if you want to run your own tools, then you need a sidecar. The sidecar is described in a plugin.jammel, and the plugin.jammel describes the init, the generate, and the discover stage, where the discover stage says if this file is detected, please don't run the ARGO standard tools, but run my plugin container. You have to tell ARGO to, well you have to tell your sidecar to have an ARGO entry point, the ARGO-CMP server, in order to communicate with ARGO-CD. So once you've done that, you're on your own. You cannot chain it with the built-in tools like Helm and Customize. If you want to use them, you have to use them again. And also the Helm chart for ARGO-CD, it has no structure to say, okay, define my plugin.jammel and this needs to be in there. It's just a plugin.jammel, so the best thing to do is to embed that in your plugin container image. And also the sidecar, you have to really define the whole sidecar as an extra container. We also wanted to use Multisource, which came into Beta in 2.6 in ARGO-CD, but it's Beta, so it's better than nothing, so it has no support for CMP yet. There is an open issue. Okay, so what did I mean with computational transformation? We wanted to do something very simple, check some into some jammel file somewhere. And we tried to do that with Helm, and it has a function to do that, but apparently it doesn't work for Helm dependencies. You cannot do it properly. The same for Customize Go plugins, very nice, but they are not portable. So if ARGO changes the Customize version, we have to compile that plugin again. So that's how we got to KRM functions. KRM functions are defined in a spec. It's donated to CNCF6CLI, Customize is already using that. And it's basically you have input items, which are KRM objects, and you have output items, which are KRM objects. Then you have your function and a set of a configuration for your function. Now, we got lucky because Customize, like I said, has already alpha support to run these KRM functions. So we started using it like that because KRM functions need an orchestrator. Okay, so we're ready. We have our plugin. We can put everything together. But then remember, we cannot chain things. So we got lucky again. We started from Helm chart and Customize has support for Helm charts. So we could do in a quite nice way our Helm integration. We didn't need to write first do this with Helm and then do this with Customize. It was just one step. And then there was also the issue of no executable permissions because the KRM function isn't executable. It needs to be really set as an executable, and that was not done by ArgoCD in the KITS repo that was pulled in. This is now resolved. You can configure that, but still it's a bit of a security question if you do that. Okay, so now done. We have our plugin and it works nicely. But with all the steps that we had to do and the fact that we had to use Customize to inject a simple checksum using a KRM functions, we were also thinking what if we want to run these KRM functions as defined in the spec as containers. Containerized KRM functions. And we were not the first one who were thinking that. So there is an ArgoCD issue open for that where there is a proof of concept to do this with Docker in Docker and Potman. But again, why would we do that? We are running in an orchestrator called Kubernetes which can run containers with can run pots. And we have a good orchestrator called Argo workflows. So what if we let ArgoCD translate a customized style of chaining things in a Jamel file? It doesn't have to be the customized Jamel. And ArgoCD translates that to an Argo workflow. That means we could get a secure and hermetic set of transformation and generations like in Customize using Argo workflows. And as the picture describes there, the workflow is started. First you have, for instance, a Helm step, then you have a function, a KRM function. And at the end, the output is KRM. To check out this medium post from somebody else who actually thinks in the same direction. Okay, so like I said, all the sample code of this idea is in this Nokia kit of space. We're open for feedback because that's why I came here. And, oh yeah, we are hiring. Thank you.