 Hello, this is Gautam from Salesforce. Hey. Hello. Can you hear me? I can hear you. Okay. Can you hear me? True. Yeah, I can hear you. You can, can you hear me? Hello. Okay. No, can't hear you. Okay. I think now I might hear you. Hello. Can you hear me now? Now I can hear you. Okay. So, um, let me introduce this, this working group meeting. Mm-hmm. Cause I really don't think someone else will join and we just call it. Okay. But. Uh, so I'm over. I'm. Uh, one of the active. Uh, people in this working group. Other. Is Thomas. Uh, We generally take this part. Um, so the working group is about operators. We are a part of sig up delivery. Um, this is the goal to define what an operator is. Under the CNC. And concept. So. Why is an operator in general and then go a little bit deeper in. How an operator in Kubernetes is built. Okay. So. I'll show my screen. Let's give me just a second. So can you see the white paper? Yeah. Okay. Great. So. Basically what we are doing or aiming to do right now is completing the operator white paper. And the way we are doing it is that we take sections. And each time. You can pull request with a couple of sections, give it a week or two, and then merge it. I don't have the GitHub right here, but it's somewhere in the notes. And so let me give you a brief introduction about the white paper. You can. At any time, just go in and comment and add or delete stuff. And generally what we're doing in this. So. So. The meetings is going over and just approving or discussing changes. So just execute summary. And introduction, which will both be written. The end. So it's kind of forwarding here. The goal is like I described earlier at the target audience. And then we're going to move on to the next question, which is basically a more generic talk about the operators. The operator design. A little bit to the. I've been like actually developing some of the operators using. Available operator generation frameworks like Q builder. Operator SDK. Previously generated code using code generators and client go alone. So all of these things. So I. One of my questions is more about so when you talked about like more generalistic approach of what an operator should do and. What in the world of Kubernetes. How we can define an operator like where can I find more information about those architectural discussions that happen for generic operator versus Kubernetes operators. So this is basically the operator design pattern. More general approach that where we think. Where we think about a software that have the operational knowledge what and current is called a controller. And it was some declarative state report some declarative status. And manage some resources. Yes. So it's just taking the concept of a controller into. More generic design pattern. In the sense that we don't define it in the wording of controller and we're not requiring it to run and extend the Kubernetes API. Okay. And after we described. This part. This also describing the character. Characteristic to fit sorry for that. And there is the Kubernetes operator components which is taking the design pattern but giving it the right names. So here you can see the tutorial. It watches. Custom resource. It reconciled the desired state. Just the old things that you builder and everyone else gives. Out of the box. So once again we talked about the little bit control and custom resource. And control loop. And the second part of talking about. Operators in general. Are the operator capabilities. So we wanted to find few capabilities. That an operator can say I'm implementing this capability. And this, if you know this capability, you know that I'm doing everything right as it written. For example, an operator can have the install or ownership. Capabilities and then. The operator will know how to provision everything to check everything. And or to take ownership on external resources that were already provision. And for example, the, the, there can be the backup, the. Scaling the auto scaling. Uninstalling. So all this is our kind of. Capability model that we try to build. And. And. The third part of more general operator is the security and risks. Which is once again, we don't want to get inside of. How you write a control. That controller itself. So language and all that. That can affect the security and risks. But that's. A little bit deeper than what we want to describe here. But yes, we want to describe how you build trust. How you. And. Discuss the information you need. How do you monitor the audit log. So the more general thinking. And less. So. That can be. Good if you're running inside the cluster outside the cluster or maybe. Even if you run some terraform in a way that it can continuously watch. A guitar for example. Okay. Another quick question. So. This. So care about. The authorization and authentication with controller. Being like a native support for any of such kind of authorization authentication within the controller itself. Like. Is that the whole different chapter. So in general, we're not. Proving or. Signing any operator it is. We're just trying to lay down the foundation of what an operator is and what. But we're not, we will not take part on. Proving or for. Adding or vetting for operators. Okay. Okay. Okay. Yeah. That was answering the question. One more question is. So. Are there any kind of guidelines. From the perspective of this thing. When to opt for an operator. For example, an operator. Can be a state full set or not. Can operator be. Scalable in a sense that there could be multiple. Versions of a. Controller of a given operator. And load balance among them. Does this say lay out any kind of guidelines or. Or is that all sort of scope for this. So. I'm not sure. We will probably need to discuss. Somewhere around. Even in the general design pattern. So is this software is. Should be only one of it or should be. Able to scale. Should it keep state. We should probably go into it. I'm not sure if the documentation goes into it right now. But this is a great part to dive in and add. Maybe somewhere in this section. Or in the control section. And yeah, I'm not sure if this is written right now. There'll be a very hard guideline around it. Maybe more in the discussion of, okay, you need to. Understand you might need to know how to scale it. Don't keep state, for example. Okay. And so. Yeah. Good. So just. On the wording, we are not a Sieg. We're a walking group under Sieg up delivery. So we're okay. Very specific task. And once you might close down and say goodbye. Okay, okay, okay. Make sense. Totally make sense. Yeah. Yeah, I had it. I thought this is that our Sieg meeting. So I was asking all kinds of questions. This is a very working. A working group. Confined to one particular area of discussion. Yeah, I think those are the only questions I have regarding this. I actually have gone through this document. Not very much in detail, but at a high level. Yeah, I think that this document actually helped me a lot in understanding where the actual design comes. Comes for this, the Kubernetes operators. I think. I found the answer. Yeah. Thank you. Thanks for that explanation. Great. What usually you do. Like, once you convene and meet here, like what is the outcome of every working group meeting. Yeah, let me just a second. So, and generally we go over the document and solve. And comments and additional texts. And as we try to get a good consensus inside the working group and then go out in a public PR and get consensus in a bigger. And then we try to finish the end result. Will be a document that we will present in the SIG up delivery and get the SIG approval for it. And that's from there. I'm not sure, but from there, that's the SIG. A responsibility. Okay. So this is an ongoing process, not short one and with all the situation this year. So, yeah, going slowly. You are welcome to add comments. As I said before, and every one you can add multiple people right. If you want to share your part, write it up or even delete it and write it again. And we also have a Slack channel. The CNCS Slack called SIG up delivery operator working group. And so also feel free to jump there as questions. Sorry. And walk around. I think that all the holidays and the situation around people didn't join today. Probably next meeting we'll have more people. Yeah, yeah, totally makes sense. Yeah, so I should be able to comment at any comments in this document. Yeah, I think that comment is open for everyone suggestions. Okay. It's not just right in the channel and I will figure out. Okay. Sure. Yeah, makes sense. All right. Yeah, I think that's it. From me, I'll try to put my comments or questions into the channel. I think that is more active than putting comments here in the document. Great. Thanks. It's great to have you here. We'll have more people joining and contribute. All right. Thank you. Thank you very much. Have a nice day. Thanks. Goodbye. Bye.