 Greetings, everyone. I'm Esgi, and this is Loro. We are engineers at UpBound, who is the company behind Crossplane. And today we are going to talk about our recent Crossplane Development Experience improvements, specifically focusing on the Crossplane CLI tooling. I'm sure you all know about Crossplane, but let me start with introducing it. So Crossplane is the cloud-native solution for provisioning cloud resources. It can encapsulate different resources or policies behind a single MPI, so that users can self-service them and just start using them without becoming an infrastructure export. It has lots of cool functionalities. Go check it out. But due to our time constraint, we cannot just cover all of them. But we have a deep-dive talk tomorrow, so please join us, and you can get more in-depth knowledge with that talk. Okay, so Crossplane is awesome, but as any project it has a lot of pain points. So there are more than we have written here, but I'll just go through this once, because for this once we have some solutions. Some of those like where to start with writing providers or functions, how to do it in a standard way. Writing compositions in Crossplane can be difficult. The dev loop can be long and slow. You can get everything ready and then you can have some validation error in your schemas because of some missing required fields, for example. Or your Crossplane is running, but your claim is not ready, and you have to do a lot of digging to see what is going on. So all of this can waste a lot of time, and it's frustrating. So lately in the Crossplane team, we have decided to invest into developer experience improvements. Some of those were focused on fixing and improving the development cycle, and some were for making it easier to work with Crossplane. So to start, by the way, we improved our CLI, so all of these commands are basically CLI commands that we have added to our CLI. And I'll go through some of them. So the first one is init. So imagine that you have a cool idea about a new provider or a new function, and you're thinking, okay, but what to do now? Go through docs, think about it, how to start in a standard way. Well, with init, you can now just use our CLI to initialize our repository for a function, for a provider or a configuration. We have a set of predefined template repositories, but you can insert your own if you would like. And if the repository has an init script inside it, or notes, it will print out the notes and ask you if you want to run the init script, which will help you initialize your new repo and customize it to your needs. Okay, so you have started implementing your function, or you just decided to use one of the existing ones in your composition. But do you wonder what will happen when you apply that composite resource to your cluster? Well, that magic can be previewed with the render command now. The rendered command gets the composite resource manifest, the composition function, and it downloads the functions, the function packages, or just uses the ones you are locally running. And then renders everything and outputs the XR resource, and followed by the cross-plane resources that will be created. So in the output, you can see everything the cross-plane will generate after you apply it to your cluster. And you can get this information without deploying it to an actual cluster. Once you have your cross-plane resources prepared, there is one more step that you can do on your local cluster, which is validating the rendered output or validating your existing compositions or resources. So the valid command downloads the packages. It can be a provider or a configuration. It extracts the resource schemas, and then it stores those information in its local case for future references. It validates the cell rules, or it can check any schema errors. You can catch them offline using the cache you have already, and you will have more confidence about your generated resources once you apply them to the cluster. Okay, so you did everything the test gives you, and you're pretty confident that everything will work. And you deploy everything, and you're waiting for the resources to get ready. And you're waiting, you're waiting, you're waiting, it's not getting ready. So, okay, kubectl, this, kubectl, that, try to find out what's going on. The claims can create a lot of resources, so it's not always simple to debug what's happening. But with a new trace command, you can get a tree-like view of the related resources, and you can then easily see which resources are misbehaving, and you can try to fix them. And furthermore, we added also a top command for cross-pane. For now, it just shows the resource usage of all the cross-pane-related pods, like functions, providers, and core cross-pane. But in the future, we're planning also to add there some metrics to have more information about what is going on in the system. So stay tuned about that. Okay, that was all. Thanks for your attention. Please feel free to check out the CLI documentation and provide us some feedback. We are really appreciated. Thanks a lot. Thanks.