 Welcome to Cloud Native Live, where we dive into the code behind Cloud Native. I'm your host today. My name is Whitney Lee. I'm a CNCF ambassador and a developer advocate at VMware Tanzu. So every week we bring new presenters to showcase how to work with Cloud Native technologies. We'll build things. Today we will definitely break things and we'll answer your questions. Today we have a wonderful human and one of my very best friends, Victor Farsik, one of my best. There we go. Victor's here to talk to us about diving into Kubernetes testing techniques with Cuddle. I think that's how you say that. Cuddle and crossplane. So this is an official live stream of this. That is, is it official? That's how you say it, Cuddle? I don't know. It's your stream. I'm a guest. How do I know how it's going? Okay. I need to get through this stuff. This is an official live stream of the CNCF. And as such, it's subject to the CNCF code of conduct. So please don't add anything to the chat. That would be in violation of that code of conduct. So basically be kind and respectful to each other, to Victor, to me, to everyone, even your people who are just around in the room around you. Anyway, friends who are joining us live, please, please say hello in the chat. Tell us where you're viewing from. And as always, if you have any questions, go ahead during the presentation, go ahead and put those in chat. We want today's presentation to feel more like a conversation. So we'll answer your questions as we go today. And with that, I'll hand it over to Victor. Victor, tell us about you and about the presentation today. About me? Yes, I'm Victor. And about the presentation, we were just discussing before this start to kind of like, hey, did you prepare something? No, I misunderstood the instructions. So the presentation is no slides, nothing. So what I really want to explore. So here's the story. Okay, let's be serious for a second. Stop smiling with me. What I thought to do is to figure out how to write tests for one of my projects. I have no tests over there, right? This is a virgin project. I do have a bunch of Kubernetes manifests. I did not practice. I did not prepare material. The idea is to figure it out, right? I know a couple of tools that we should use and things like that, but kind of completely unprepared of the grid. Let's figure it out together type of approach. I love it. Off the grid, you didn't even have electricity up until five minutes before this presentation. So we're, this is down and dirty. Exactly. So this sounds super fun. So we're using this tool that neither of us even know how to say it. It's, Kate, let me put a link in the chat. K-U-T-T-L, right? And we're going to use that to write some tests. Say, okay. Is it time before we hear your screen? So Victor and I, we host a show together. So why the stream feels especially silly. We really are very good friends actually. Victor, we have, we have best friends brazenly. Oh, they're not coming into focus. Okay. Well, yeah, there it is. Best friends. Okay. So we just did a QCon keynote together in China. We host a show together called You Choose on Victor's YouTube channel DevOps Toolkits, where we do a choose your own adventure style journey through the CNCF landscape. So that's why today feels extra casual and silly, but we're going to do some very serious, serious work here. It's going to go, it's going to be fun. And quick. Serious and fun. Okay. Yeah, yeah, that could be both things. We have great, loves tons of hellos in the chat. We have people here from New Delhi, from South Africa. That's so, so awesome. Thanks for coming. Are you ready to share a screen and kind of get into it? Yes, sure, sure. Yeah, go for it. You press the button, I guess, right? Or something like that. Yes, I do. So, let me do a quick intro, right? And with me or any of the guests in questions, and interrupt at any moment, I like to be interrupted. And the main reason why I like to be interrupted is because I tend to interrupt everybody else. So otherwise it would be double standard, right? So the story is that I am, or I was really freak about testing, right? I even actually the first book I've wrote was Test-Driven Java Development or something like that, right? In the meantime, I moved into Kubernetes and all the good things that we are doing today. And the other day I had the need to refactor thousands of lines of YAML of my Kubernetes manifest to change it to something else. And that's something else being from YAML to Q. And then I realized, or went back to my golden days that, hey, if I'm going to refactor, if I'm going to rewrite everything and expect the same result, I better start figuring out how I'm going to test that, right? Yeah. And it's almost unfortunate that testing is almost a norm. Everybody assumes that we are testing everything but except when you come to Kubernetes, then actually we don't. Or at least it is very rare, let's say. So I looked for the tools, searched for the tools and it turned out that according to my limited searching, limited time spent in searching, there is only one tool that potentially can help with that and that's Kutl, one of those, K-U-T-T-L, right? So the idea is, yes, the idea is to, let me actually show you what I have here. So this is my cross-plane composition, my cross-plane composition is related to databases, everything to manage databases in Arch. AWS, Google Cloud and what's not right. And there's, let's see, there is, we see that there is almost 900 lines of pure YAML that I want to convert into Q. And before I do that, second, of course I will. There we go. Thank you. Amor, is that good? That's probably fine. Anyone can speak up if it's not good for them. Yeah. So the idea is I'm going to rewrite this to Q and before I rewrite this to Q, I want to write tests that will confirm the current behavior and then when I start rewriting that, I want to run those same tests and expect exactly the same output, write the same result. I have a question. Yes, please. So as you know, I'm relatively new to Kubernetes and you and I together have been working through all the CNCF tools and I guess I want to know why have I never heard about testing in Kubernetes before? I guess before now I assumed maybe it was just like more happening at the application level then. Yes, because many of the things get started and propagated by application developers. We had years of struggle to convince all of us to actually that we should write automated tests to do things that was happening 20 years ago. And very often in certain areas and testing is certainly the case, the rest of professionals or experts or people tend to follow later. We are still, there are small percentage of faster testing infrastructure done by Terraform rather tools, but Kubernetes, very few. Not nobody, but it's not common. So is it maybe just because Kubernetes has been changing so rapidly and it's just now becoming a mature technology? Is that related? Just that it's changing. Something rapidly changing is an additional reason to do testing, right? It's actually the argument in favor of testing not an excuse for not doing testing, right? Okay, so the answer is you don't know why it hasn't existed so much yet and it definitely should. No idea, no idea, exactly. I don't know. I know a couple of projects in CNCF landscape that are using Cattle, the one I'm going to use today. So it's not nobody, it's just not very common. Okay, and then specifically what we're testing here is Kubernetes manifest? Yes, so I want to test that couple of things, right? I want to test that manifest that I create as they should be, right? But it goes further than that, right? Because very often, in this case I'm using Crossline, but I'm going to use Kubernetes deployment as an example, right, because it might be easier to explain. You want to, you write the YAML that or Helm or VITT or whatever you're using that will create that deployment, that's cool. You want to test it and say, is this deployment exactly as I want it to be? And that's the easy part. The hard part is that, yes, but that deployment will create a replica set and that replica set will create pods and those pods will create some volumes, right? So what you really want to test is not only the direct, this is what I've wrote, that's easy, but you want to test, okay, so will my deployment create that replica set, right? And will the replica set be the exact specification I want? And will it create pods? And will those pods won't be what I want? And will those pods create volumes and so on and so forth, right? So it's the complexity there, I mean, it's not really big complexity, but the challenge there is to figure out how to test not only what you write, but all the child resources and modifications that Kubernetes itself will make as a result of applying that something. Okay, super cool. Okay, is that, yeah, go. Let's just give a little, lots of chatters happening in the chat and I want to say hello to everyone. We have lots of people here, California from Belgium, from London, from Chennai, from Bangalore, from Moldova, from India, amazing, amazing, amazing. So thank you so much for saying hi and where you're from. We have an ominous thing that says, cuddle is good, but something better is coming. So. What is it? I want to know because we can discuss. I actually think that Cattle is horrible. Yeah, so the thing I'm featuring today, I don't think it's exceptionally good. I just don't think that we have anything better. So if anybody knows of a better solution, I would be really grateful. I'm gonna say Cattle is horrible. I don't mean it's horrible, but the main problem with Cattle, the one I'm going to use is that the last release was almost a year ago. Okay, oh, so no one's really. So it's kind of not really well maintained and all that stuff. All right, well, tell us what better is coming, please. We have a Nuno says hello, our friend Nuno. And then we have more amazing, like hello from Chile, hello from Colombia, Argentina, Toronto, India, another Colombia. That's great, Italy, with another India, France. Okay, I gotta stop reading those, so we'll do that all day. But we have a question about Cattle, which is can we, and this is a question I had too, can we test Helm chart deployments with it? Is it gonna work with all the different ways we can write application configuration, CDKs? Yes. Yeah. Yes, so what we are really testing or at least what we'll try to do today is I'm testing the result of what happens when I apply this to a Kubernetes cluster, right? And doesn't matter whether that's something is generated with Helm or with Pugh, YAML, in my case with Q, actually, I probably don't have time to go into Q, but doesn't matter what it's generated from, I'm testing the result in Kubernetes cluster, right? And that means it can be anything. Because all those tools in the end make the YAML and the YAML testing test it. Exactly. Cool. And then to answer a question about what's better, they say chainsaw is the tool that's coming that will help us test Kubernetes in the future. Okay, Whitney, now you need to do a solo for a minute until I write there's a note to myself. Check chainsaw. Chainsaw. Do you have advice, Victor, about where one can learn more about testing? For one, you could just stay in the stream with us for a while. And... Yeah. Uh-huh. And we're asking, did you miss an introduction to Cuddle? We haven't said too much about Cuddle. We talked about Kubernetes testing generally, how there isn't really a lot of Kubernetes testing tools out there. And then what we talked about was the trick was not just testing the configuration itself, but all of the child resources and grandchild resources and great grandchild resources that get created from that manifest. Exactly. That's the challenge of Kubernetes testing. Exactly. So I can explain Cuddle, or I can start writing the Cuddle stuff and explain while I'm doing it. What feels better? Option two is what I choose unless the chat speaks up and so on. Good, because I forget things so fast that I already forgot what's the option one. But let's go for it. Option two. Cool. So what I'm going to do is I'm going to create a cluster using kind, which is, okay, this is not a good beginning. Oh, I know, I need to start Docker. If I take a second. By the way, this is- Please do man again, please. Of course, there we go. Yeah, as you already mentioned, I lost electricity. It came literally a few minutes before the stream. So I did not start the stuff. More things might be failing than usual. Let's see. Docker container LS, it's working. Okay, kind delete cluster. I'm going to delete what I did before and start from scratch. Okay, there we go. So I'm going to create a cluster, Kubernetes cluster with kind. The reason why I like kind is that it's fast to create, fast to destroy. I want to destroy everything I did after I'm finished, but everything I'm showing should work in any Kubernetes cluster, right? So it doesn't really matter. We're waiting on that. We have a question. Yes, please. It is, I'm new to Cuddle. It looks like an end-to-end testing approach, correct? Can I do integration testing with it? Depends how you define integration. So you're testing really Kubernetes resources, right? In a cluster. So you can test it on any level. As long as we understand that we are talking about testing the validity of resources, not necessarily what is running in your containers in that cluster is correct, right? So is the deployment correct? Does it create a replica set and things like that? Kubernetes resources from the perspective of are they defined and created correctly, not necessarily what is running as your applications in that cluster. Okay, keep up the questions. I love that. I'm going to create the directory tests. And this is cool because you see that I did not even have the directory test. This is really starting from scratch, right? And I'm going to create something called Cuddle test YAML. Now, this is the file that tells Cuddle what to do, what to execute, what to set up and so on and so forth, right? So the first thing is API version is Cuddle.dev. I'm likely going to make mistakes. So bear with me, better one. And the kind is test suit. Cool. Now I'm going to say that test dirs are going to be, I'm going to store my tests in the directory, let's say tests, right? There we go. That's where I will keep my tests later, right? Once I start defining tests. And now I'm defining the setup and configuration and all this stuff. And this is now going to take a bit of time. Commands is, what are the commands? What do I want to execute as a setup? Before I start running tests, right? What are the prerequisites that my cluster should have to be ready to execute the tests? So since I'm running using, I want to test my cross-play manifest. I'm going to install cross-plane. Install, install, and cross-plane. And it's going to be cross-plane stable and cross-plane. This is the chart and the namespace. Space is going to be cross-plane system. And I want to create that namespace in the new cluster. And I want to wait until cross-plane is installed, right? So we're talking about setup. And the next one, I want to, since I'm testing some cross-plane compositions, I'm going to apply, apply whatever is defined in file name providers.aws, right? So if you're not familiar, cross-plane has providers like, hey, this is how you manage AWS, this is how you manage Azure, Google, and I will need how to manage, since we are talking about composition for databases, how you create users in that database and so on and so forth. So I will need to install all those providers in that cluster, right? And that means, yes? This is a good segue to a question and maybe a comment about questions generally. We're getting a lot of questions, but some of them aren't related to the matter of at hands. And I think the ones that are not related, I'm going to save until the end. We'll do a more general Q and A, just in the interest of moving this all along. But one of the questions, which I think you're kind of answering now, is can I test resources that were created with cross-plane in Azure or AWS? So I'm going to make that question more general. When you use any CNCF add-on tool to extend the Kubernetes API and make Kubernetes resources, can you use Cuddle to test any of that? Yes, yes, you can use test any type of resource in a Kubernetes cluster, no matter what it is. I'm using it to test cross-plane. You can use to test typical Kubernetes stuff like deployment spots, what's or not. You can use it to test, let's say, policies with Kaverno, anything really. Anything that Kubernetes understands, you can test. Or at least I haven't found the limitation yet. Yes, if anyone has, please do speak up. We want to hear about it. And so, and it's worth maybe saying for those who aren't familiar with cross-plane, what cross-plane does is it takes any API on the planet and it makes it so you can interact with it as a Kubernetes resource. So when we're talking about Azure or AWS in this context, we're talking about bringing those resources into Kubernetes and interacting with them as though they're Kubernetes resources. Exactly. So I'm going, so, and then how is testing with Cuddle different from something like Helm unit tests? With Helm unit tests, I do not use exclusively Helm tests. And I'm not, but I think that that would be very useful. But Helm unit tests are more concerned about whether you defined Helm templates correctly. I'm more interested in this case, whether what will be applied to my cluster is correct. Excellent. And then what Bernard, you're asking whether we can test Oracle Cloud infrastructure resources. So if it's a Kubernetes, if it's defined in Kubernetes as a Kubernetes resource, we could test it. And if not, then we cannot. Exactly. If it's defined in Kubernetes, the answer is yes to any type of testing of the resources themselves, not the process is running over there. Excellent. All right, what have you been up to during this conversation? So I've been setting up, I've been setting up things like, okay, I want to, whenever I start testing, I want to install crossplane. I want to apply some, I want to apply my composition itself, right? The first actually providers. I want to install Google, AWS provider, Google provider, Azure provider, SQL provider, and then my composition, right? That's what I'm really testing here. And then I started writing the commands to wait until they're all healthy. I probably can skip that part. And because there are quite a few others, and if I do skip, I think that I'm done with the configuration. Something will not work. Of course. Let me say that. So is the idea to spin up a whole new client cluster, install you everything you need, test your manifest, and then you can tear down that client, and then you feel it's tested, and then now you can apply this to something else? Almost. So what I prefer since I have quite a heavy lifting over here, quite a lot of things needs to be installed in a cluster. I prefer to create a cluster, install everything that needs to be installed, and then apply the things that I want to test, which I did not get to yet. Run tests and destroy those parts, but not the setup. I'm going to keep the setup. I'm going to destroy everything apart from the setup, but keep the setup so that I don't waste too much time. Okay, I guess I'm surprised by how much is happening at the beginning. Like when you run these tests, how many commands are happening before the tests are actually run? Yes, depends. I'm guessing that many people will have much simpler setup than I do. I'm just going crazy here. I love it. Bring it on. Exactly, and it failed as it was expected. Let me see what I did wrong. Okay, yes, cube cut will get, let me see. Okay, so I did not set up to wait for things, and I'm just going to run tests again. It will eventually work once all those providers are up and running. Let me actually, while waiting, let me, or you can come up with a question. Otherwise, I can check what I did wrong. Howard, one question we got here is how would we use this tool in a CI CD context? Oh, you would run the same commands that I was, that time running in a CI. So I'm executing now a cube cuttle test and the directory tests, which actually is not needed because it's specified here. So you could run the same command from, let's say, GitHub actions or whatever you are using, right? Great question. And I figured out that I forgot to install this. And now it should potentially work. Now it is installing stuff and it's not failing. And there we go. Now this will take probably a couple of minutes until everything, I actually know. Yes. We do have a question, a test related question. Is the test coverage features user-friendly and cuttle compared to Terra test when testing with Kubernetes? I haven't used Terra test. So I don't know. Another thing for me to write down and figure out. Excellent. If anyone does have experience and wants to speak up, we're all yours. Test, so let me start by defining. So now I'm switching to tests themselves, right? I'm going to define the first set of tests and the setup specific for that test, right? And so I created the directory Google. I'm going to test my Google manifest. And now the important thing is that cuttle works by convention. It will always execute things that are named 00 and then 01 and then 02 and then 03. So it goes sequential based on the prefix of a file, let's say, right? And the file names can be two types. It can be assert.tyaml or anything else. And if it's anything else, anything but assert, it will assume that that's a setup for that specific test, right? And I'm going to say, okay, let me install first something specific for that test, that something will be deleted at the end of the test. And that something is I'm going to create my crossplane claim. And for that, I need API version. First, I'm going to create a secret V1. Okay, no, kind is going to be secret and metadata is going to be, let's call it my DB password. And data is going to be, oh, my. Echo dash n, oh, my password. And then I'm going to base 64 to encode it. That is going to be my fancy password. And so here we go. Password, autocomplete is messing with me. There we go, right? And one more thing, and I'm done. I'm going to say API version is going to be DevOps toolkit series.com, V1 alpha one. I said V1 alpha one, there we go. So I'm defining now my crossplane claim, SQL claim. This is what I want to create in my cluster metadata. It's going to be called DB, that sounds good. Spec, I like autocomplete. It makes me, it makes it look like I know what I'm doing. There we go. My DB and composition selector. If I remember correctly, provider is going to be Google official. And DB is going to be PostgreSQL. You can probably imagine that I spent a lot of time with those things, so I know it by heart, yes? For those who haven't used crossplane, this is a custom resource, like a custom way to extend the Kubernetes API that Victor's created using crossplane so that he can manage a database, a Google Cloud database that's completely external to Kubernetes as a Kubernetes resource. And so that's what, yeah. So you've already written the Kubernetes, the crossplane resource to do that and you're referencing it here. Exactly, exactly, I already have those things. Those things are working, I just want to test it so that when I start refactoring at some later date, it all works. So now, yes, I sensed a question there. In response to the Terra test, how's this test coverage compared to Terra test? They say Cuddle uses Yemo, which is easier to be used instead of Terra test, which uses Go. So that's one difference, right? Okay, I'll commit a test for your infrastructure code test. I'm just, I haven't used it. It sounded so much like data from that I didn't consider it. I'll try it out. So I don't know, to be honest. A test infrastructure code with Terra test enforced. This seems to be, Terra test seems to be very much for Terraform when they are looking for something very specific to Kubernetes. Oh, I see here, oh, there is, sorry. You cannot see on the screen, but I'm looking at it. Yes, I'm going to try it out. But the answer is right now, I don't know. Excellent. It was, yeah. Nothing, that's all for it. We have another question of Cuddle can help me understand if there are memory leaks in my Kubernetes deployment. No, it tests the Kubernetes resources. It doesn't test what is running in your containers. So it's not replacing your, let's say, testing of your applications, right? Functional testing, integration testing, whatever. So it's not replacing your tests. It is just focused on confirming that what you wanted to have, what you want to have in Kubernetes cluster is what it is, right? From the, from Kubernetes perspective, not from the perspective of what is in your containers. If that makes sense, does it? Maybe? It makes sense to me. Yeah. Okay. So what I'm doing right now is that I created Assert. So I, this is, this is what will be confirmed when I execute Kube-Cuddle-Cuddle, it will check whether whatever I define in this file really exists in my cluster, right? And whether it has specific properties. So everything that I define in this file will have to exist and be exactly as a specified, right? So they will have to be this API version, this kind, not kinds, and metadata will have to be my DB, right? This is what I specified. This is what I'm telling to create. And this is what I will test whether it's really like that in my cluster. And some of the things will be the same. So spec, some of things will be different. Like for example, here, I'm not specifying composition reference, whatever that is, right? But since I know that cross-plane, when it creates resources, it adds additional things that are very important. I want to confirm that that is really happening. So for example, composition ref should be named Google official PostgresQL, right? I know that Kubernetes cross-plane will add this, I expect them to add this to the resource when it gets created in a cluster. And this should be the ID and composition selector is another thing that is not something I'm specifying, but I know that it has to be there and it will be this one. And parameters are going to be the same as here, which means version 13 and small, right? So I want to confirm that when I apply those two, this is what I will get in my cluster. Make sense? Make sense to me. Okay, so I'm going to run it again and it will go through the setup again. This will be fast because everything is already up and running. Then it will executes this install here, right? And now it is testing whether what was created in a cluster is what I specified in 0.0 asset. And most likely it's not because I know it's not because you see how it is waiting here. It is hoping that maybe that something will be created soon. And I can show that SQL claims that you can see that it created the... The setup, yeah, the catalog created this SQL claim in this namespace, myDB, but there is something different between what I specify that I want and what it really is. And after the timeout here, let me see the timeout I put to 60, I'm going to reduce it for the future to be 30 seconds, not to wait that much. After a certain amount of time, it gave up, right? I said, hey, I couldn't find what you're looking for. And here in the output, you can see, this is what it found in a cluster, right? It did find some SQL claim. And there are some fields that exist in the cluster and I did not specify in my asset. And that's okay because you don't have to specify every single detail, right? What does matter is that what you do specify that exists and you can distinguish those by the minus. And here's a minus and says, okay, look at this. You expected to find this. And here it is. And in reality, what I found is this. I made a typo there, right? That was my mistake, but basically... You can pretend you did it on purpose as a teaching model. Exactly, exactly, right? I believe you. You expected this, this is what you got. There's something wrong. And if I now run again tests, it should execute much faster. And SQL claim, it is already deleting the namespace. So it is shutting down everything that I created and it passed, now it works. Cool. Right? Any questions before I move on? I missed how you got to the place where you could find what went wrong with the test word. It hung instead of passing. I knew because it was waiting here for a while. So it hung? So, yeah, so it said here, you see, this is what I saw. This was the last line and it was hanging there. It was hanging for 60 seconds because that's what I... Because in Kubernetes, there is no guarantee the fact that something doesn't exist this very moment that it will not be created by later, right? So it needs to give it a try, right? And after the time out, it gave up and said, okay, this test failed. This is the output. Okay, that's the output after time out, got it. Cool. We have lots of questions. Oh, that's cool. Yeah, this is great. I've really enjoyed. Can I answer this one? You can double check my work. I don't see the question, so I don't even know what you're answering, but that's fine because I'm looking at my monitor. Oh, okay, so you can't see our stream right now. So the question is, what's the benefit of having external APIs proxied by crossplane and exposed as Kubernetes resources? Well, so there are three big benefits of this. One is, when you bring it into Kubernetes, you can now use the Kubernetes control loop to watch the desired state or the actual state and make sure it's always in sync with your desired state. So you have synchronization and drift detection. Number two is that you could use it with any other tool in the Kubernetes ecosystem. So we could do have policies that now are Kubernetes policies that you can apply to your external resources. You can do GitOps now. You can define your desired state in Git. Use a tool like Argo CD or Flux to sync that to... You just find it in Git using crossplane resources. Sync that to your cluster with Argo CD or Flux, and then crossplane will do the work of syncing their external resource. So now you can use GitOps for your external resources. And Victor, so sure I have this covered. He's just like thinking ahead. I'm already working on the next one. Exactly, I have full confidence. And then the third reason, and the third reason is that with crossplane, you can offer a simplified claim. So you can have an expert configure what you want your Google Cloud database, for example, to be configured like at your organization. And then the people who need to provision that database, who need to consume it, can have a very simplified interface for only see the knob that they need to see to be able to make those change, to be able to provision that database or whatever external resource that you have. So that's the answer. Yeah, that's a good one. Yeah, great. And so now this, so about back to Kuddle, does this support cluster updates? If you want to check whether your resources after the update are keeping defined correctly and they are present and they did not disappear and things like that, yes, yes. Cool. I think this person is requesting examples of Kubernetes resource that Kuddle can test. But really, so far as far as we know, any resource in Kubernetes that's defined as a Kubernetes resource can be tested here. I'm testing resources that are not even baked into Kubernetes. So this SQL claim that I'm testing here, this does not exist in Kubernetes. This was brought in by crossplane in this case, but it can be anything really. And the next question, can Kuddle check the state of resources? Check if it's in a ready state. Yes, yes. So I could, I'm going to mock a bit here, right? But I could say status, right? Because status, and then I don't remember exactly, I could have did, this was now autocomplete, right? But state, bond, whatever, right? So yes, you could check statuses. You can check anything that is available in a resource that includes specification, metadata, state or anything else that might be there, yes. Cool. Another question, can it test if security context is applied to a pod? Yes. That's also part of the definition of a pod. You could, whatever security context, colon, is this or that, yes. Yes, I like saying yes. Great. Yeah. And we're caught up on questions. We do have some other questions that were asked at the beginning about just how to learn Kubernetes and we're saving those for the end and staying on task for now. Yeah, as you choose, I'm following your lead. I'm trying to stick with stuff that's related to this stream in particular and see what kind of time we have at the end. So like before I said this, I'm creating something called SQL claim, right? And I'm testing that that SQL claim is indeed in a cluster with all the properties, right? But then there is that concept in Kubernetes that one resource might create another resource which might create another resource and so on and so forth. Like deployment creates a replica set. In this case, SQL, in my case, I expect it not only to exist, but it will create something called SQL claim not only that it exists, but it will create something called SQL without claim, right? And I expect it to have some specification. So this is a child resource. This is not something that I'm telling Kubernetes to create, but it will create as a result of creating something else. And let's say claim ref should be API version, for example, I know that by heart and kind should be SQL claim and name should be my DB, right? So I expect this SQL claim to create inside of the cluster, this one, I do not need to tell Kubernetes explicitly that should be created, but that's what will happen. And now I want to test that that is really happening, right? So I've wrote another assert. This is now 01 assert.yaml, execute tests again and then if everything goes well, it will, if it starts immediately deleting an SPS that means that it immediately confirmed, found it and it passed, right? Let's say that it, no, it should have been xxx just to say something, right? Just to get it wrong. Exactly, now it will wait for 30 seconds, hoping that it will somehow automagically appear and 30 seconds later, you will see that it failed and you will see the diff plus and minuses. During this 30 seconds, let's go with a question. Are there any options of storing the test results for future reference and get some tabular output if we have many tests? Probably. The reason why I'm saying probably is because I never tried it myself. I am very much into test-during development, meaning that if it fails, I'm fixing it right away. I'm not trying to find how to store it, but we're going to check it together right now. But before I do that, you see how now it found, okay, here it is, right? This is what you said you want and this is what you got. Now, first of all, you can store this output somewhere, right? You can do just T and then somewhere.txt, right? But I suspect that CubeCuttle has other outputs and we're going to check it. Let's start ArtifactsDeer, the config planes here, or maybe it doesn't report. Specify JSON or XML for report. Report location determine, there we go. And there is a name as well. So JSON or XML, those are your options. Cool. I like watching your problems, so that helps me learn. No other questions right now that are related. Do, yeah. Okay. Let's see, how much time we have? I can continue writing tests until the end of time. Or if we're at a good stopping point, I will go ahead and revisit those first questions. We have about 14 minutes left in the stream. Yeah, because the rest now would be, imagine that I'm not on the stream, now I would just continue creating tests. I would probably need a hundred tests, give or take, which might be boring to look at me do all hundred. Let's all do this marathon together. How is Cuddle different from Kubernetes linters like KubeLint or Dottree? Very different. Linting in general, without going into specific tool, is checking whether the syntax of what you're defining is correct. So for example, there is no such thing as myKind, right? Sorry, myKind, this does not exist in Kubernetes, right? So Linting would tell you, hey, you cannot define something called myKind. And also, Linting would typically go through the schema for that resource. So it would go to Kubernetes class to find the schema for SQL. And if I would say Victor is cool, then it would say, no, no, no, Victor, exactly. First of all, by definition, by default, it would not even need to check the schema for that. But apart from that, it would go to the schema and say, no, you cannot, there is no such thing as, in the schema, there is no such thing as spec claim ref Victor, such a thing does not exist. Now that's very different from texting, right? It would say, Linting would say, cool is okay, right? Kind of like Victor, if Victor field exists, it is allowed to put any text into it. Now, this type of testing is there, no, no, no. Did you really want to have cool here or not cool, which is more likely, right? And there was a second question, Linting and Dutry. First of all, Dutry is bust, unfortunately, because I like the project, but bust, it's no more. Yeah, the company behind Dutry, unfortunately stopped any development. So it might not be a good thing to use. And I like Dutry, by the way. So Dutry is looking more for not testing whether you're getting what you want, but it is testing more for best practices, right? Oh, you forgot to specify the requested amount of resources and limits of those resources, right? It's the best practice for you to specify that, right? So it will tell you that, or it will, yeah. So please specify amount of memory that your application should use. That's the best practice that will tell you. Now, testing, on the other hand, like this, you would specify, no, the pod created through deployment should have specified in this condition, one gigabyte of memory, right? That's kind of confirming that what you want is what you get. Dutry would not tell you that, oh, it should be two gigabytes of memory, right? Because it doesn't know what you want, but it does know what is the best practice and what is not. I have a comment that I want to verify. What I think is happening and I want you to make sure. So you shouldn't, with a tool like Cuddle, you need to say this field exists, like because not if it's a key, if it's a value, yes, but not if it's a key. Because if it's a key, that should be caught as part of your custom, when you define a custom resource, you're giving it a schema. And then that when you actually create a custom resource, it's being compared against that schema by an admission controller, correct? And so that should be caught already by that Kubernetes process. And so the thing you're using, yeah. Let's say that I remove metadata name, right? It is mandatory to have a name, as far as I know, right? Now, if I run the test again, no, those are not tests, there we go, right? After 30 seconds, it will show you different messages as before. It will not show you, this is the difference. It will tell you, I could not even find the SQL claim, right? There is no such thing as SQL claim, somewhere in the logs that should say deleting namespace, good, failed in step. Let me try to find, creating namespace. You see, I did not experience that myself. I never failed in this way. It should say somewhere, somewhere, somewhere, somewhere. Anyway, it's somewhere it says, ah, yo, here we go, here we go. Resource name may not be empty. Right? And this is now not, this is the response that it got directly from Kubernetes cluster because when I tried to apply this, Kubernetes said, no, no, no, no, no, no. Stop, Victor. Don't be a fool. You're not allowed to do this. That came from a Kubernetes admission controller, not from... Exactly, exactly. And Catholic just passing it through to me, right? And so let's get at these older questions that don't have to do with crossplane or cuddle. And they're both very similar and they have to do with advice around what's the best setup to learn Kubernetes. So one is wondering if it's GCP or AWS. The other one thinks maybe it's an Ubuntu laptop or can you use Windows? Those are the two questions that I was saving for later. And those in chat, interested in your opinion too. Yeah, so you can run it locally. I tend to use either kind like I'm doing today which is running on top of Docker or... Kind, the acronym kind stands for Kubernetes in Docker. And basically every node is really a Docker container. Exactly, if I do Docker container LS, you will see that there is one container running and that's the container created by kind. And basically my whole Kubernetes cluster is in a container. Now, I could go to Docker and let me find where is the preferences settings, right? I could go to Docker and just enable Kubernetes. I don't think I can enlarge this. I don't know, I can. There we go. I could enable Kubernetes and then I wouldn't need to use kind. I like kind because it allows me to create and destroy Kubernetes and start over whenever I want it, right? I don't like to keep random things floating around. And if I would enable it in Docker, then I would need to go and press the button. And I'm lazy, I don't want to press a button. So I use kind. And apart from that, my favorite for local is Ranch Desktop. Again, anything, Minikube would work and many others. And going, now there were a couple of questions. The first one was Windows. What I was answering was for Mac and Linux. Sorry, for Mac, for Linux, you don't even need Docker. You can run kind directly in Linux because, sorry, you need Docker. You don't need Docker Desktop. You don't need Docker client only. And for Windows, I don't know because I don't use Windows but as far as you know, Docker runs there and it should work fine, Ranch Desktop as well. And then if it's remote and you're looking for something easy among the big three, Google Cloud, Google Azure and AWS, personally, I think that Google is easiest, GKE. But if you want to run remote for the sake of trying out things and kind of getting a feel of something closer to a real cluster, I think that Civo is great. I would recommend Civo because it's very, very cheap and very fast. Civo. And when we're talking about Windows, Mac, Linux, we're talking about your laptop's operating system. You're still ending up running Linux machines when you run nodes, correct? Probably. I think, I'm not sure. I think that Docker running on Windows might be enabled to run Windows containers as well but I'm not sure. Yeah. So when you're talking about learning Kubernetes, Kubernetes is existing across multiple different computers. And if you're doing a local cluster on your laptop, you're finding a way to simulate the fact that there are lots of little computers working together that you're interfacing as one thing. And if those little computers, if your laptop has Windows, that's one thing, that's fine, but if the little computers you're manipulating as Kubernetes are Windows, it's my understanding that that's adding a level of complexity that you probably don't wanna add as a beginner. Yes, not as a beginner, just forget about Windows containers that I would suggest going to that later, kind of, that would be additional skill to learn because all the lessons in Kubernetes are, most of them are equally valid for Linux nodes and Windows nodes. So don't complicate your life with Windows right away. And even if you're running Windows on your laptop, Docker by default, if I'm not mistaken, we'll be running Linux containers on that laptop. Yes. Excellent, those are, and now we're, we hit the bottom as far as questions go. So if anyone has any questions, please do speak up. Otherwise, unless Victor, if there's anything else you wanna demo, it might be time to say goodbye. Yeah, I mean, now it's, I'm, now I have like four hours spending in front of me after this to write all the tests I wanted to write. That's it. And the part that didn't show here because I did not want to go too far away from the topic is to write also a lot of queue code to replace my demo. Ah, yes. And so queue stands for configuration, Unify, execute. Execute, I think, yes. Yes. It's a language that is a mixture of, let's say, go and JSON. So if you mix those together and they have a baby, that would be cute. And it's very, very good for, it's actually, it's not the easiest one to wrap your head around like the first hour, but once you figure it out, it's my preferable way to define stuff. Well, this has been an absolute joy, Victor. Thank you for being on the show. I hope we can do this more often. Come on, Cloud Native Live regularly. If you're telling me that I have to do a show without preparing anything in advance, I can do it every week if you want. I'm gonna say, this is a dream for me. So those of you who don't know these Cloud Native Live shows, specifically we ask our guests not to do slides and we want these hands on demos. We want it to break. We want to learn together and have a conversation. And so that's also very much Victor's style of presenting. So it's a match made in heaven. Let's do this all the time. Yeah. All right, so that's it. Thank you so much, Victor. Let me put this away. I do have an ending script to read. Thank you so much for your time and attention to everyone who's here in the chat. It's been a wonderful chat today. Thank you, Victor, for sharing your expertise with us. And here we go. Let me find that, sorry. So thanks for joining today. It's great to have Victor Farsiq here, teaching us how to dive into Kubernetes testing techniques with Cuddle and cross-bling. The chat was amazing. Thanks everyone who watches the recording. Here at Cloud Native Live, we bring you the latest in Cloud Native Code on Wednesdays and sometimes Tuesdays, always at the same time, which is noon Eastern. Thanks for joining us today and we'll see you next week. Bye.