 Hi. We'll wait a few more minutes and then start. Hello. Sorry for coming a bit too late. I wasn't allowed in the meeting. Let's wait another three minutes. So, Kevin, I think you are new here, aren't you? Yes, I am. And where are you coming from? From which company? So, I work for Red Hat just now. Perfect. Before that, I spent four and a half years at Heroku. So, I have a lot of experience of describing applications to run in containers. Perfect. Okay. Just a second. I'm organizing my desktop at the moment to find out which documents I need with her. I think we have too much documents. Yeah. And we'll probably need to move some of them or all of them into the GitHub repo. Do you know if Jennifer will join us today? Jennifer, I think she might not be able to join. Okay. Yes, then let's start. Hello, everyone. Welcome to today's Operator Working Group meeting. Yesterday, we want to discuss how we will proceed without a comment. How you can contribute to our working group. And what the current topics are. We are about to change our workflow a bit currently. In the last few months, we worked on a Google Doc document and found out that this is not always the perfect way to get such a document. Currently, we are about to change everything to a more concentric workflow. So yesterday, we created a lot of issues for which are currently to do in our document. We have tried to migrate everything to the CGAP deliveries in the repository. So if you look in the CIN safety repository, sorry, a new one is joining. Hello, Winnie. Hi. You are also new here, aren't you? Yeah, this is my first time joining. Okay, perfect. Then I'll try to repeat what I said before. Welcome to today's Operator Working Group meeting. Yes, today we will discuss how we want to proceed with, we are currently creating an Operator White Paper. We want to discuss how we proceed with the White Paper. Omar Jennifer and me created a lot of GitHub issues for this White Paper. So everyone is invited to take on issue, but to say he wants to deal with the topic and to work on this topic. And we are also trying to get our document to edit our document in the GitHub repository of the CGAP delivery. So we can discuss changes on pull requests and so on, but not discuss many things over and over again. Yes, currently there is no fixed timeline for the White Paper, but we are working on it at the moment. So we will see how many people will contribute now and how our progress, how our document gets further. Yes. This was the introduction. At first, how can you contribute? Just let me share my screen. Just a second. So I think, do you see my screen? I think I've shared the wrong screen. This should be my browser window. This is the GitHub repository of the CGAP delivery. And now there are a lot of issues, tagged with Operator White Paper and we also wrote Operator Working Group in front of them to make sure that you see that these ones are from us. And we tried, in some cases, we tried to, yes, we tried to describe what should happen there. If something is insufficient or you need something, don't hesitate to contact Omar, Jennifer or me. And also if you would like to work on an issue which is not already created, you can also open the issue, open up the issue and we will address it. What's missing in our case at the moment is we don't really have articles about the different Operator Frameworks, such as the Operator Framework itself, as Q builder, as Kudo and so on. So if you know people from these communities which want to join us and would like to contribute to a document and do a modern work. Currently, so if you want to contribute to one of these things, you can only comment to it if you want to take responsibility about one or more sections, just contact us and we will assign this issue to you. Yes, and this was this part. So this is the, these are the open tasks at the moment. The second thing is, we have an operator working group space in the, in the CGAP delivery repository, where you find all of our meetings, the links to the link to the charter, the agenda and meeting notes, and so on. So this is a current document of the Operator White Paper. Did any one of you read already the current White Paper, except of Oma. I think you read it more than enough. Yes, I read it. Okay. Is there anything unclear to you, was the target, the goal of the document unclear to you? No, it's, I mean, it's a fairly limited document, but it seemed reasonably okay. So what you can, what you can see the document at the moment is there are lots of to do's and we tried to migrate all of these to do's to the to the issues. But at first we followed an approach where we created sections in the document. And afterwards added this track wanted to try to add this to a PR and merge this in the delivery repository. This is a bit of a weird process. And therefore we will try to get anything to keep. And afterwards, only leave a comment at the White Paper that everything's in it. Yes, so to the document itself. We as a CNCF project want to create the White Paper, which targets on operators, obviously. More from a from a bit of a higher level so not not only for cubanitas and not only for one framework, because we think that operators can only exist outside of cubanitas. So, this was, this was the, the thing why Omar created a section about an operator design pattern, because when you think about operators or how an operator is structured. You could also think of Terraform about Terraform as an operator, because it also has a controller with which is Terraform itself. It has custom resource definition or desired state let's say this way, which would be the description of the Terraform, which would be the Terraform script itself. And it has infrastructure where it is applied to, and which it can reconcile. So, in a very basic and abstract way you can think of think about that there are operators outside of a cubanitas landscape. So what we, what we tried to do at the moment was we, we were describing how operators work and try to describe this on the basis of a cubanitas operators. Because these are the only operators that people know at the moment. So, this was a thing where we said, yes, we have cubanitas operator components as a controller desired state and objects to be watched. And yes, we describe, we are trying to describe a lot. And afterwards we thought about what which capabilities could an operator have. And all that there is currently operate the maturity model, which says in this phase and operator supports this and this, in the next phase and operator supports this and this. And we tried to break this up a bit and say that we don't have a maturity model in this. As it, as it is in the rather document, but we have capabilities and we could say an operator has the capability to install an application okay that's a bit obvious. But it can also have the capability to manage the backup of an application, which is not as obvious as I think, or it could deal with auto remediation of the underlying service, and so on. So, the idea was to describe what how an operator could help an end could help and user could help a user and which features could be interesting for an operator developer to implement. And what we what we are. Afterwards, we try to describe what we think about this. How this should be. So, one of our own goals is to set standards in the form as an operator which supports observe which supports, which has monitoring and matrix and is good, good observer. We must use this endpoint and you and make it and expose it for this software. So we want to keep this a bit more open, so that the people know what they can use, or how, how such, how such things could be deal with. The things we also thought about and I think this this has also be a can also be discussed a lot. We had the capability of scaling so that the operator supports the scaling of the application. Let's think about no master elections or other things, but an operator could also support the auto scaling of an application. So it manages the scaling of the scaling, but what I thought what we found out that at a later later point that scaling the operator itself could only be a could also be a very interesting topic. And if you're exactly if you think about watching and remediating reconciling the deployment ports or whatever this operators managing. Yeah, so we had that we we defined a lot of, lots of capabilities so if you find another another capability, please only feel free to discuss this in the slave group or in the GitHub issue or whatever. So I think as many capabilities we have as, as clear it gets for customers or for also for developers, what an operator could bring could do for them. And afterwards, we thought about, we thought that it is fine to know to know what operators are for. We will get some some best practices and so on. But we also think that the exact that the security and possible risks of operators are very, very important. So, especially how can a customer ensure that the operator he wants to install. This is security requirements. So, let's think of think about signed port, signed container signed images or the openness of the code and so on. But also, how can I as an operator developer ensure that customer trusts my operator. So, which information could I provide to him. Think about permissions on the API and so on. And therefore we also try we're also trying to get the security a bit more in the boat. And also, also other other security related specialist. So if you if you are more from a security. You have a strong security background you're more than welcome to contribute on this. Yes, and the 1313 security for God was the end user observation so how can how can end user ensure that everything the operator said is really true. Okay, yes and now we have some operator framework such as let's let's describe, let's call them the operator framework let's call him cool. And however they are called. And therefore we thought about that it would be very cool if we find some people from the respective communities to describe their approach because I think not every operator framework has has the similar approach. And I think this is all true. And to what we want to ensure is that every, every, every community feels represented in our fields, correct, that it's currently represented in this document. And we also thought about some time about the operator frameworks for now, for now you will need to spread firms, some called sunset to true that's on the project, I think. But that's, we have we have not too much about this at the moment. Another thing we also have to operate the life cycle management so how does the operator itself get managed and so on. And what also could be interesting for everyone would be the would be use cases for an operator. So, this could also be that the section will be a bit more more on the upper of the document. But I think it is very important, especially for users who want to develop developers who want to develop operators, which use cases they can manage with this. So, which is me, which can be caught also covered in the capabilities, but this would be special use cases. And what we also want to achieve is to get some some best practices for operators so I think we hear we, we hear and read a lot about operators. But there's no white people, anything which collects all of this best practices and so on. And this is one of one other part we want to achieve. So, often there, it's talked, there's operators and operator operators mentioned some people talk about the placement of operators, so that you won't. And we would like to operate your workloads and your control processes operators on the same notes or not of course, but I think this can be can be discussed, and so on so. And also how can I publish an operate an operator and how can I find it. After that, we would like to outline a bit of technical implementation details. So, how can I write an operator how can I start to write an operator in this case it is especially for communities that's true. So, find a framework find out how an operator works and so on, but also how can I test an operator. Yes, how could, how could a demo application implementation of an operator could look like. So, I'm not sure if you if you know it but there is a demo application in the in the city delivery which is used for demonstration purposes of deployment mechanisms. I also thought about describing an example operators, not only in the document but also in the repository for from the city get from our working group on top for this for this application and only reference to this in our document so that everyone who wants to use different capabilities has a blueprint on this repository. Let's say this way. So this, this was only also more an idea than we would be in the situation that we can implement this at the moment. Yes, and afterwards we will round we will sum this up and conclude on. Additionally, we know that there are a lot of books and white papers about operators. And we all we also want to mention them and to give credits to them because I think for some things we've written written there. So us is is from there. But we also want to ensure that everyone knows what we are our document differs from this. It's not to have a bibliography and after that we can publish it. Is there anything in terms of structure. In your opinion. So, also, especially not for moment because he knows the document. No, structurally, I think it's fine. I mean, obviously there are some minor detail things missing from it. Like to me one of the things you probably have to standardize on is logging and things like that because clearly you don't want to have to have multiple log formats be empowered you all of anything that you can reduce your friction with is going to make it but technically I think document structurally thing. I've built a number of operators. I could probably contribute to some parts of this. Okay. And let's say this way. Would anyone like of you to sort of Kevin or we need would like to contribute to the document or which parts would you like to contribute. That's a good question. I could probably write about writing operators using the operator SDK they go home slash thing I've written a number of go beast operators. I think you've actually written a tutorial for some bits of this so I probably could expand on that or drink a little bit and get something out. I think you currently have no issue for that could you write an issue what you, what you would like to propose, and I will. I will take it in this and assign it to you. I mean, I think the key, the interesting things about it would be to look at it through the lens of the maturity model, you know, to consider what what basic parts of it get you to the first level what you need to get to each of the levels and build on top of the levels to get to those positions. That's probably my because I already documents about how to take operator SDK and build a really trivial operator but it's that maturity part that's interesting what does it mean to provide deep insights what does it mean to provide about the fifth level is like what are those things and how do you actually implement those. So you can come back to them to the maturity versus capability, capability model. What we thought about is that an operator which supports auto, sorry, I'm not sure what it looked like. Yes, an application which supports horizontal vertical scaling. Which supports horizontal vertical scaling does not have necessarily to support backup filler recovery. This was, this was also the cause why we switched from the maturity model to more capability based model model. Yes, it could, it could, it could have also make sense to to have have have such levels to find out how much how mature the operator is, but in our terms we we try to avoid such things. Let's say that we might want both so there is the capability model that's the thing that operator can do. And some operators, for example, don't need to do backups because it's not relevant for them. So it's not maturity leverage the capability, but in terms of maturity. We can say an operator has phases maturity like security is one logging the tracing is one and and like the building of the operator that writing with the code has mature. But in terms of capabilities. We have some examples that operators that only creates other objects so they don't actually need to backup anything external or even though doesn't have to support the vertical scale or or something like that. And a lot of it is, I mean, it's interesting to me right so like I look at an operator is how do you automate away your problems. What do you do on a day to day basis that you would like to not have to do in a fail worthy way. And so like I look at it as backups, some services don't require backups, but a huge amount of them do. So, you know, I would probably shy away from the things that don't need backups in favor of how do you make backups useful how do you make that level of maturity useful to folks. It doesn't necessarily always mean literally right now dumped a PV or something like that. There's other ways to think about that problem. So, I often thought about think about operators. I was, I was working as an SRE and infrastructure guy. Long, long time of my career. And what I'm thinking about is that operators are replacing my work. Yes, that's why I think. So that's also what makes them an operator not a controller. And yes, and what we all I'm trying to be what I, or what we tried to be to describe in the computer model was exactly this type these tests we did from day to day so I'm sure that our application is correctly scaled that it's backups are running and so on. For me things it's other you know it's essentially, you can see what get ops is right so get ops is operations by get was that operations part that that's interesting to me operations. The next to operations is just deployments probably hasn't done a lot of operations work. And there's a myriad of other things that need to be done by folks to keep systems running and operational. Yeah, definitely that's that's interesting part of operations. I think a lot of people who think it's just deploying things. I think that we don't have it in the docs but I think Thomas you talked about a few times there's the day one and the day two. I think this was Mark Mark yeah. The day one is installing and wrapping up. And they do is like keeping the application healthy. Yeah, rolling secrets on a regular basis. Yeah. Those things of operations. I mean, I don't have to go far back very far to think about the kind of operational tasks that were carried out on the services that have operated. So I think often when people talk about operators they think about installing an application. But to be honest, if I only want to install an application. And we want to describe which, which, which features an operator could also provide to them. And what other main, let's say, pros of an operator, except it's, except it's complexity. Okay, or what do you have something to add. I want this. Kevin does everything until now makes sense to you do you have. Do you have any expectations, other than the things we and me and Thomas and me has talked about so far. I'm pretty happy with it. You know, I'm fairly familiar with the landscape. It's a lot of chilling to do some of these things already. And so shifting it into operators and cube isn't really much of a change. So when did you have some expectations of the operator working group. No, so I've been writing operator using Q builder. And I just saw this I, I was just curious how other people are writing operator and so this working group seems interesting. So I went with the white paper. This also very interesting all working group. So, um, if I understood this right, you, you did not write right. Very much operators. No, in, in my team, we are, we are writing operators. We are actually writing many, many controllers using Q builder. Okay. I'm going to understand this. And have you made any, any experiences with operators you would like to share with the community. Any problems you are dealing with, which we should cover. I need to think about it. We also want to make this document for the for the community and but for us. So if someone of you finds problems in the real world makes findings which we should share with the community. Let's, let's discuss it in this leg channel. Also, you can, you can always feel free to write an issue for them. I'm, I think you're muted. Yeah, yeah, sounds sounds great. Yeah, I think this is a very interesting work so you let me let me go back and read the white paper and see where I can contribute. This will be very, very perfect. Thank you. So, anyone, does anyone have something to add. Okay. So then I'll give you some minutes back. Thank you for joining the today's group meeting. I think the next working group meeting will be in about two weeks. And if it's not in the since I've killed at the moment I will let it let it let it. Sorry. English is not my native language. And I think it will be really cool if you could join us and contribute to the document. And if you have any questions or any expectations of proposals or whatever, just feel free to contact us. Thank you to us. Thank you. Have a nice evening everyone. Thank you.