 Hello. Hey. Good morning. Well, it's early in the morning in your time zone. Yes, I'm California. So. Okay. So are you. I'm from Austria. So it's evening. My time. Yes. And my daughter was in Budapest. So I used to track that type of time zone for a while. The COVID stuff. I'm a little bit of a broader home. So. Hey, everyone. I think we. But I think I can start. And. So I'm. I'm part of that. Co-chair. Of the. This working group. Thomas is another co-chair here. And Jennifer. He's the. Third culture. She had some. And the events at home. So she doesn't have. Internet right now. What we'll do today is as usual. Short introduction. And then. Talk about our draft. Question and desk assignment. For we start John. And. Holy. To pronounce it. And I froze. Right. Yes. So. Okay. It's a long, it's a very long line to over some time. So he, so he freezes at some point. Yes. Hello. At first. I think so. Hi. You are new here. Aren't you? Yeah. For sure. Yeah. Yeah. Okay. It's a very long line to over some time. So. So he freezes at some point. Yes. Hello. Hi. You are new here. Yeah. That's the first time I'm attending this. Yes. And. Do you want to introduce yourself shortly? So that we know. And give us an idea. What do you expect from our working group? You want me to go first? Yes. Okay. All right. Yeah. So I work at a company called info blocks. We do have a open source project info blocks open. You can go look at that body of work. We're used to be a public company, but now we're a private. The firm. Owned. And we have had traditionally an on-prem solution. In the DDI space, but for about last four years I've been working on our SAS solution. Which. As you would expect, you know, is a cloud. Native application. We built it from ground up. We have something like. Over 200 microservices. And a lot of tooling for it is on the open source project, because when we started the project. You know, on Twitter and but if you were writing Java. You know, or note or some of those more or Ruby. There were some toolkits available, but for go at the time. There wasn't anything. So it's a lot of toolkit elements are open sourced by us, although we don't evangelize it or anything like that. But, you know, since we wrote it, we put it out there. And so we've also been on this journey. Kind of building the CI CD tooling today. Today we use Spinnaker for our pipeline. We've been using Spinnaker for about. Over two years. In production. And. In the new target state that I'm working on. We want to migrate to. A Kubernetes native environment. We've gone through the whole, you know, Docker swarm. On mesos Kubernetes journey as well in that four years. But we've always been cloud container based architecture. So, but, but different orchestration. Peace underneath. And so we want to migrate our. Pipelines. And we've done a lot of POCs around. We've done several projects today. We use our go workflow for our. TI pipelines. Looked at our go CD. Flux. Flagger rollout. We've written our own. Operators. We're heavily influenced by the work and by the backstage. Community in terms of the end of end pipeline. And we've done a lot of work on that. You know, that kind of a declarative way to define the apps and the overall life cycle. Everything from creating it to. Monitoring it to. So that's kind of a target state for us to get to. And so we just see this. But I couldn't. What I call an application operator. It's kind of a critical piece of that. And so we're trying to get to. Are using. You know, various. Everything from the group builder to the. Operator SDK. And. And others. So. So let's kind of give you an overview of our company myself and kind of the overall target state that we're trying to get to. And so. I've been attending the application. But I was, you know, And I, it's been on my list, but my mornings are fellow with scrums and meeting. So this today, I didn't have anything blocking me from attending. So I thought I would attend. Nice to have you here. Thank you for the introduction. Yes, we are very, very short, short, small, sorry, no short, but small. We are dealing with operators. One of our main goals currently is to get to write a wide paper about operators so that users and users and old, but also developers of operators know what you can do with operators. What you can take care of and so on. Yes, this working group, I think we are one of the older. Okay. The most recent operator we wrote, that's open source actually, is a cluster operator that we wrote because one of the goals we have is to be able to declaratively create clusters on demand. And so we use today cops in-house. But there's a lot of flux in the company. I mean, around using EKS or using EKS control. And it was just, and so our goal was, and there's cross-plane. So one of the goals we had was to create an operator that kind of overlays and creates a invariant representation of a cluster that you can operate on. And then all the choices we make around kind of what the tooling is underneath is kind of hidden from us. And also it becomes more multi-cloud. So that piece is, and so mostly in POC right now. But like I said, So you might have a lot of knowledge about operators. Well, like I said, we've written lots of operators. So that I look at it as more like a blank canvas and then you can kind of do something. And I guess the tooling for it, like I said, over time has gotten better on the point of view of the community. But... Okay. So guess our current state is that we are, as I said before, we are currently writing a white paper. We are currently in a state where we have our first, I think our first draft deadline next week. But we don't have enough content at the moment, let's say this way. So if you want to contribute something to the white paper, you are more than welcome. Yes. So, yes, let's start with the rest of the agenda. I think, Joan is also here. I didn't expect him to come today because it's very early in the time zone, I think. And yes, I'll just take a look over your work. Currently, it looks really nice. Have you, do you have any questions currently, or do you need some input from our side? No. So we're aiming to have this draft wrapped up this week. We were trying to have it done before today so I could tell you guys excitedly. We both got busy on last Friday. So we're, I'm nearly done with my section, Cameron's hoping to spend Thursday on it. So we should have that in a state previous review. So I guess the question would be, do you want to review it in the Google Docker? Do you want me to submit a PR in a markdown format or what's sort of your guys' next steps? For us, it would be cool if we, if you could put it in a public list. So we end all of the other people could review it. Cool. Yes, we'll try to, we'll try to accept it because as soon as possible. I've been trying to get more folks interested to join this working group. I'm not sure if that's been successful yet or not, but I'm trying to help. It's perfectly fine, thank you. We'll also try to make the tasks a little bit more clear, I think. And that's something that came up in the SIG. We'll review the task and make them make sure they're more easy to pick up when you join us. You were a bit, how could I say this in English? I could not understand you because there were some policies in the group. We will, we need to go over the tasks and make sure they're good for new joiners. Some of them are good to pick up very easily. Some are less and we'll do it this week to make sure that if someone is wanting to join, it's easy to do that. So the next task we will write will be a bit more clearer and a bit more better defined currently. Just for your information, we copied everything from a Google Talk to Markdown and to the Git repository and so on. So we shifted our whole workflow in between of writing the document to get this a bit more structured and therefore the tasks were very clear defined. Thank you, John, for your contribution. Thank you. I hope the security tasks were defined well enough. I'm a little surprised at Omer's comment. I thought it was, at least for me, it was easy to understand, but maybe for others. Okay. So, yes, we have, today, we have the nice task of assigning the rest of the tasks, I think. These are a lot. So at first, so how do you want to write something for the white people or don't you have got enough time for such things? Well, I was going to start by actually reading it. So I just pulled up the Git site. And I was just looking at the body of work. I'm surprised it's not using make doc, but it's fine the way it's laid out. MK doc, I think you can, if you're going to do something like this, might be a way to organize it. It's just, typically that's the pattern people are writing documents and get, but I'll read through that. We have a table of contents. I'll go through and read and sounds like we generally accepting pull requests for updates, right? Yes. Is there sections that are empty right now? And you want people? Yes, there are a whole lot of sections that we try empty. Okay. All right. I'll start just by looking at the document. First time I'm looking at it. But please, if you, if you plan to do something to write something this contact me or someone, then we could block this chapter. So we have, we've got tasks in our repository. And then we'll send this to you. And hopefully no other one will do this. Okay. Yeah. I'll look through the task to them. That's good. Okay. MK docs is for presenting the document in HTML, right? No, it's in Markdown. It just, it creates a doc folder. Yeah. It's still not something that will be easy to implement. But do you think it's, will be easy to implement that in our current? Yeah. Once you have Markdown, you could essentially just create a project for documentation and it shows up as a doc folder. The pattern is more for, you know, having a coexist with other things. And because this right now, the whole repository is one big document. Let me, let me find. And there's also material version of it. For fans here looking at UI. So it's, let me find a link to it and I'll put it on chat. Okay. Um, then I think we'll try to, um, go over the current past. So, um, well, let's see. To address. As this month or. I'm sorry. We're aiming for a draft to come out this month. Right. Or next Wednesday to be, to be exact. So it's a lot, it's a lot of work for one week. But it's. But I think it's like in like a new university. This also worked to work the whole time. To be honest. Okay. Let's go over tasks. Okay. Um, so for everyone who doesn't know this, um, Yes, we have, we have a lot of document parts. These are different documents. And. For almost all of these on document parts, one past in the, in the. Part exists. We have some past which are assigned already. And we have some past which are not designed. We should do this now. Um, I think, uh, we will include Jennifer afterwards. But, um, that's no problem. Okay. So, um, Yes. Um, we have. We have defined a lot of capabilities and operator can help. So, um, you might, uh, some of you might know that there are capability. The majority models of, of, of operators. And, um, there are a lot of capabilities defined. And we as a since the project, we didn't want to, um, to say that an operator who has capability X is more mature than another one. Um, because he could lack of other capabilities. Right. To only to describe the capabilities and operate the code. And, um, This should give an end user also develop an operator and idea of what you can do with an operator. Therefore, we defined a lot of capabilities. Um, such as, uh, the most obvious one to install an application to operate an application. Um, seamlessly and as backup recovery, auto-reunification and so on. And for all of this capabilities, so-called the ones which are not written at the moment, there are also existing issues. Such like the auto, auto configuration. Um, So, um, I'm sorry. Um, And the customer should be able to take the operator, which, uh, which could be out that you would answer. Um, So, Um, So, Um, So, Um, Um, Um, Um, Um, Um, Um, Um, Um, Um, Um, Um, So to keep this short, um, is anyone there who wants to deal with this section어주 How'd I get. Okay. Okay. Then we have auto remediation sections. It's, uh, will write an operator could, could be use to, um. Yes. Get an application or get an application to run the stage from a, need to take a state. We have data recovery, this is all, this is faster than the new. Then we have such kind of a very direct section, which just should describe which work already exists. So there is an announcement from CorelS where operators are defined and so on. And there are a lot of points about our work. We want to, we want to, if we does the possibility to get further information about operators because I think the white paper we will write will also only handle a part. And yes, so it's also a thing which will be done by me, I think. Okay, then we have summary and conclusion, this is not a really problem now. Does anyone want to deal with the technical application or the technical implementation of an operator? So how can I write, how do I start writing an operator? How can I test an operator? We could describe all of this using a new application if we want and we could give some example of the implementation of different capabilities. And but also I wanted to describe shortly what could a hard and very patent for operators could impact. I think we need to change this task because we don't really want to write, to describe how to write an operator. We have a section about implementations of operators and so maybe it's not just introduction to them. If you want to write an operator, you can use those tools or see those guides. And well, just about the methodology how you could start writing operators or not regarding the exact tool set. But what should you consider before you want to write an operator? What you should consider is a better way to say that, I think, but it also big task and maybe we need to split it. I think we won't have an interpretation of. I'm not sure the white paper is a place to talk about implementation. I think an overview of kind of the landscape in terms of what's available and maybe some links to them, I think. And like I think we just, somebody discussed, I don't know, I think discussed just a high level of how to approach and understand the use case. I mean, in some cases, depending on what you want to do, you might want to write a very low level controller versus because you want more control versus something like operator SDK where a lot of the tasks have been abstracted out and you just write a controller. So, I think. Yes, I've changed the task a bit. So we should describe on a very high level. So not too much detail. What should we consider? Where could we start when we want to write an operator? So this might also include find out which tool set fits for you. Then there is something to test operators. I think this could also be a thing which could be interesting for a present people. Then yes, the implementation of different capabilities. So I think we could drop this, but also I think kinds of the requirements for operators could also be interesting to get ideas how such things could look like. So we only should make... It's very late today, so I think it's very bad to know. So we should give users an idea how a delivery pipeline could look like and not how they should do this. So I think this would be enough over you for our white paper. What do you think, or do you agree? Is anything missing in the technical thing? Or should we rename the section or include it to the best practices section? It feels like this section is like kind of summary for the whole white paper. Kind of the short version of what because if you read the whole paper, you probably know what to consider because you understand what an operator is. So maybe we need to postpone this to after we have the best practice and more content in other sections. Just a second. We also have a best practices section where I think nothing of those are in. So there's some kinds of... Sometimes the placement of operators is discussed. So that they are separated from the workloads and so on. Then we have some metrics. Then we have on bailout operators, which I will also sometimes point of discussion. Yes, best practices for operating implementation could also include such things. Yes, then I think we will include this additional thing. A thing called umbrella operators. We look at them at least in our system as being federated. I think that's the term we use for those operators that are managing others. How do you call them? We look at them as being federated. There's already several groups working on federation. At least at Infobox, we have this concept of clusters that are more for control functions. So they overlay or they federate other clusters that are running workloads. So there's that pattern we established. I guess the term umbrella does kind of indicate something over or something else, but just terminology, I guess. It's all terminology here. Yes, we talked a lot. I think we've discussed half a year, half a year to find out what an operator is. But even the term federation means something fairly specific in CNC after is a group working on I think there's at least three groups, I know, or three projects, open source projects that are doing federations. Okay, then I will close this technical implementation thing. We will remove this section in favor of the best practices section. I think it's okay for Boomo. I think so. We'll probably need to revise this decision after the first draft. Maybe we'll decide that there is a place for that, but for now it seems like more content that we might have in other places. Okay, then I will remove this chapter and the content will be moved to the best practices section. Okay, then we have use cases for an operator. This is more end user-related injector. This will be done by Jennifer. So she wrote that she will do this. Then we have such funny thing as life-side management of an operator. So it's about updating an operator itself and do it all. Can you zoom in for your browser? Oh, sorry? Can you zoom in the browser? Yes, yes. Great. Oh, it's a bit bigger. Yes, I'm thinking about updating an operator itself and everything other which could be in this scope. This is mainly part of the operator life-side management of things and so on. But I'm not sure if there are any similar things. I'm thinking maybe it's a little bit technical talking about updating an operator. Or the thing? Technical. And I'm not sure what updating an operator itself is just updating an application. How can we describe it in a way that we want to say you need to think about verifying your CRD for example and how to do that? I think this piece is here because there is a operator CK has a life-cycle management piece. Maybe that's why this was put here just to maybe capture that element that comes with that environment. I think operator CK I think is a kind of open-shift project and so they have a whole bunch of machinery around managing life-cycles and so. Yes, so this section was a bit targeted to this because there is such a thing as an operator life-cycle manager. And I think users of operators should know what this does or how such life-cycles could be managed. But that second bullet is the main thing. Not for operators, but in general, once you have CRs and Kubernetes, you know, there's no good way that Kubernetes allows you to manage them. They're not managed elements in the system. And so it's almost like I would say like very implementation-specific how you go about managing CRs. And so we have a lot of... Both for our normal applications as well as any operators we have is just almost they're not being... They can't be managed as part of the application. They just need to be treated as their own kind of resources. So that's kind of the problem today. Okay, so does anyone want to deal with this section? Jack, or whatever this will be? I can try to delete it, but yes. It's like that last section we talked to on implementation. It seems like... I don't know that you could, as part of a white paper, really work on it unless you almost picked the implementation and then you could maybe drill down. Awesome. This was this one. So try to get... We should try to get some sections on this. So one, two, or three, or four. And we'll see afterwards in the graph if we need this or if we could drop this. Or if this will be discussed very roughly, during the reviews, and if there are additional things to consider. Okay, then we have operator frameworks from all these platforms. Do we want to deal with this? Because that's explicitly not in our scope in the chart as far as I've seen. I also think that the section where we're talking about operators in general and not related to Kubernetes is enough. And we don't have examples for non-Kubernetes platforms operators, not that we know about them. Okay, then that's the same thing as the technical implementation chapter. I will drop this and remove it from the white paper. Okay, but we have operator frameworks for Kubernetes. And I think we have to... To operate the framework described at the moment. So this is CoptionQ below. I think we should create an issue for describing the operators to K. What do we agree? Yeah. We'll probably find someone who is part of the team. So this is a... I'll give a rough overview of the detailed description how this can be used. This is CoptionQ. Okay, then it's a piece. And I'll add the new tasks to the... So I will post them on the section to do it. Yeah, I think we had some people from operator SDK along the way. I hope they were in the channel, but we can find them. Okay. And second thing I would like to have in the white paper is I think... What is it called? Kudo. So let's try to find out if someone wants to write an update about Kudo. And the description about Kudo. Also... Okay. So these are the two sections. Are you aware of any other operator frameworks we should write the description for? Okay. Yes, I will take the overview of tasks for this. Okay. And then we'll write the executive summary in the end. So I think we will... Give this task to Jennifer. If it's okay for you. Yeah. And... Yes, I think... These were all of the... All of the unassigned sections currently. So... Yes, we have a section about auto-configuration tuning. I think I will try to do this. And this will be... Okay. So I have... If you want, you can... You can add some... Some chapters or say choose to write paper. But please don't hesitate to ask us if you have questions or if you want to have some sections as well. Yeah, I'm going to read it more. I'm trying to understand the big picture. Okay. Because like I said, in our environment... Like I would like to see if there's like a... Some sort of conceptual data model of how you think... You see the environment. You know, how does the operator operate on it? Like... You know, like a... You know, we look at some things like... Like I talked about, like our Argo rollout or flagger as already being application operators. Okay. So the question is... Do I start with that and enhance them? In other words, or do I build my own? When I build my own... Is a single operator have a concept of multiple application CRs that it manages or is it one-to-one? And I mean, those are all kind of like... Things that I would think that... I'm going to read through and... But I mean, those are in my mind kind of fundamental things that I start with always and say like... Okay, then I can go down. And so a lot of what we were looking for was... You know, like... I'm just trying to read... Alex, I'll read the document. You guys have been working on it for a while. And I'll try to get the big picture. And then we're appropriate. Yeah, I will sign up and contribute. Okay. Great. We have some section where we're talking about the concepts of operator in general. So that will be... Good to validate them. And to see if they match what you accept, what you expect. And also open PRs for changes. Okay. I have... I'm thinking you have a lot of... You have a lot of useful... You have a lot of useful... You have a lot of useful... You have a lot of useful... You have a lot of useful... You have a lot of useful cases for operators in mind. And if you wanna write one in some lines, don't hesitate it with... Do it rule except pasture, I think. Such things as you say before, should I write an all operator, should I extend the other ones, this could be a very, very important useful case for developers of operators. So I think one week ago I had a similar problem where I also wanted to do something and also tried to find out if I should write the operator myself or if I should let's say this way do a form from another one. So this could also be a very valuable use case for this. So do you have any other questions or comments or other things? Yes, then I think we're right in time. Thank you for your opinion. The next meeting will be in about two weeks. So I hope then we have to discuss the first problem. Yes, thank you for your time and have a nice evening. All right. Thank you. Bye. Bye. Bye.