 Not a lot of people here yet. Let's, I guess give it a couple of minutes. So I think Jared was going to try to join also so a lot. Doesn't appear to be online at slack right now so I guess we can. Yeah, maybe as, as these meetings usually that you're the first couple of meetings on a lot of people show up. It might be beneficial to set it out to the mailing list again because sometimes people get confused by them so just as in. That's a, that's a great idea. Um, so how that's the, the agenda here. Great. So there's not like a lot on the on the planned agenda right now. So everybody has access to the dock here. We'll go ahead and get started. The meetings being recorded will send out a link to it afterwards. But like I mentioned, there's like, there's no announcements. There's no like planned like items on the topic. So like, let's start off with, you know, kind of like putting the agenda together for the meeting today. Does anybody have anything that they they want to discuss they want to add to the agenda. Like go ahead and just add on to the dock or talk here. The only that we could add is the existing document about the operator definition that I could throw in maybe. Because I wasn't the first goal. Yep. Let me just find it that everybody has it. Dropping into the Docker. Yeah, I just had to open it up. Drop it right into. Just give me a second. We can share and discuss what is already there. Just one more second. And here we go. I can actually share my screen and we can have this dock up just in case anybody doesn't have access to it right now. So I'm sharing it. I have the dock up on the screen here. Everybody can see it. Okay. Awesome. So I think, you know, like the goal here is to continue to to define, like, you know, what what what an operator is, I think that's the first step. The word really, you know, but do do much else. Like what's included in an operator what's not included in an operator. This is like a doc that's been going around for a while. So I think everybody's hopefully had a chance to read it. Like, you know, I don't know if like, it's definitely not something we're going to like be able to like solve today on this call. But like, I think we should like continue to push forward on like the discussion and see what, you know, if anybody has any more, any further thoughts on it. Well, hey, folks. Yeah, my friend here. I actually have a lot of thoughts on this doc. Some of them I've put in it. I was looking at it again this morning. What I've noticed here, and maybe it's me, the question was originally asked. What is an operator, right? That was what was asked from the TOC to SIGAP delivery. But I noticed that the doc gets a lot into things that go beyond that, such as a capability model. And the capability model came out of the operator framework. It hasn't really been worked out with the other operator projects. And it also isn't something that was actually asked of anybody from the TOC. And so I think maybe looking at what they actually asked, like what is an operator, all the nuances to just kind of define what it is and then explain that. I think that's what they asked for and this doc kind of diverges from it. So that's my big level thing. I think this document had the purpose of collecting information that was already available out there on different levels. And part of that definition was also what capabilities an operator should provide beyond the pure technical ones. And that's why this made it in there. And I don't think we have to live by the word of everything that we have been asked to do. But also provide what is needed by the community. And when we discuss this, we had certain discussions, especially around what separates an operator from a controller. And that's why we threw it in there. This doesn't mean, however, that out of this definition, we need to have a capability model in there. We just put it in there when it comes to capabilities because beyond the operator model, there was discussions. Should it only be stateful or non-stateful workloads? So that's the reason why it's in there. So nobody said we're defining an capability model. So let me ask this then. So if this document captures a whole bunch of things, is this the document that we are planning to pass up that kind of explains here's what an operator is. Here's the outcome. Or is this a place that's just capturing a bunch of information and talking through it? This, as currently stated, is a working document. And as such, we are working here. We can rename it. If this makes it more clear. Yeah, because, you know, the working document that captures lots of things is different than kind of the output that answers the questions. And that's useful for people who walk away because the general person is not going to be as involved in this conversation as say you or me. And they just want the outcome in a short concise manner. But a working document that captures lots of things and links out to it, maybe has long form explanations. That entirely makes sense to capture all of these things. But I would suggest that a capability model maybe something that should be gotten into, but I would separate it from the definition. So that way the definition can get out there quickly. And these kinds of things that probably should be discussed with lots of different operator projects. Kudo operator framework and the other ways of doing things. We'll take a lot longer to get through and it may change drastically by the time that it comes out who knows what will come out from those long form discussions. My understanding and my hope is that this document is that working document that we kind of like think of it as the all encompassing things that may make it into that final like definition of an operator and then we can distill it down into that smaller. Like, this is actually what the definition of an operator is and if the capability model is or is not in it I think that's a decision we make but like, like we should definitely include it as like a candidate to make it into a into the into the definition over time. I don't I don't have an opinion about whether or not it is part of that but like, you know, right now I think it's like, like data collection mode what could potentially make it into the definition of an operator before we can actually figure out like what what the pick is like this is actually what the operator is defined as. Yeah, like if like, maybe we just break out like a sources or prior and sorry sorry everyone I had the wrong calendars turn on. So prior art or like research section here just to make it clear like, like this is just stuff that we are taking lead from right or just telling him because I am of the mind like maybe this is not part of the like we have a separate goal to like build a maturity model or like think about maturity models or just consider those things that only is part of this but you know there's definitional stuff that's in this capability model that we may want to refer to when building out our actual definition. I just linked the actual definition by the way that it is currently in the Kubernetes definition and the communities documentation just put it in the agenda so we have this one there as well. Yeah. And I think, like I think we're the reason that we're here is because like this current definition that's in the Kubernetes documentation is somewhat vague and lacking and so we're trying to like. It actually covers it, but it actually covers the capability model because if you can you can you bring it up because it says like deploying an application on demand taking and restoring backups of the application handling upgrades, publishing a service application that don't support companies API to discover them simulating failure and all parts of the cluster to test this resilience. So there is actually parts. Yeah, exactly this piece of so we have it currently in the communities documentation. As examples. Well, it doesn't actually say this is the capability model it's giving examples of what it might look like to do that and it gives examples here but it doesn't actually say what it is, which means logically that this could be. It doesn't mean that it's everything that's inclusive, or that it involves some kind of structure for a capability model. I think it's just trying to paint the picture of what this might be, not list what it is. It's trying to paint a picture rather than fill in all of the details. And, yeah. Yeah, I mean I think that kind of comes back to the same conversation that that's, you know, like, is an operator like, is it a CRD or or is it not a CRD doesn't doesn't require that an operator includes a custom resource definition and the controller that runs in the cluster to meet the definition of an operator it's it's kind of in that same, like encompassing area of like the definition of an operator right now. So if we look at the the original definition that came out of chorus when they they defined it. Just like I find this. So the original definition. Brandon Phillips and and chorus said an operator is an application specific controller that extends the Kubernetes API to create configure and manage instances of complex stateful applications on behalf of a Kubernetes user. It builds upon the basic Kubernetes resource and controller concept, but includes domain or application specific knowledge to automate common tasks. And that right there kind of has a I would argue three specific things that make something an operator. First, it extends the Kubernetes API. And if you look at extending the API there's actually two ways to do this. You can use custom API server, which is what the service catalog project did and that's from before we had CRDs or anything that created that right. You can do that, although it's really really hard, the much easier and more common path to do that is with CRDs and custom controllers and that kind of thing. And so I would argue if it extends the API and probably either one of those ways, most likely through CRD because it's easier. Then that's the first check right does it extend the API and if you have a controller that never extends the API at all. You probably miss that chuck box. I mean it's right in the definition of it has to extend the API and this builds upon the other parts because really what you're getting into is the declarative model. And in the declarative model you declare what you want and then the system works to make that possible. But if you don't ever have a API to declare what you want, then your operator doesn't know what you want in order to make that possible. And so if you don't have that extension, you're probably not an operator. The second thing that it gets into is domain or application specific knowledge, and it goes on to say that it has to define common tasks, right. And so you need to look at does it have it. So if something like meta controllers my example is something that's a controller, but it's not an operator because it doesn't have application specific knowledge it's a controller that actually helps you build other controllers, but something like one of the postgres operators that has application specific knowledge for postgres. Well that has application domain specific knowledge in order to accomplish something you're not going to be able to use that operator to run. I don't know WordPress or something entirely different because it's only targeted at that. And what are good the third thing is is it needs to manage instances of applications on behalf of the kubernetes user. So you know if I'm using kubectl and I want to deploy my sequel right. I have to know my sequel I've got to know the ins and outs I've got to run commands I've got to craft the files and do that kind of thing. I actually have to know kubernetes and I have to know my sequel and I've got to know the business logic and marry it. And if I want something to happen or change within my cluster like backups things like that. I actually have to go create the cron job or else I'm going to do right. You have to deal with the business logic side of that. But an operator, it says, I'm going to capture information about that application, and then I'm going to manage that application for you based on what you've done for me. Do you say you need to have so many replicas and ha do you want backups okay give me your schedule for backups, however we want to do it. We're just going to make it happen and we manage that for you. So you don't have to think about it. Right. Those are kind of the three big things that were in that definition. And if you use that definition and you basically rip out the stateful set side of it, or the stateful part of it. Right. And you just take that out. You've got those three criteria right there and you can actually write that out in the long form. And then you can test anything against those. Right. The Postgres operator and meta controller easy things to test fluxes was brought up the other day on the call is kind of that hard one to test and basically I've written up what that would look like. But this is one of those things like it's there playing his day as long as we just expand on that definition, and then we're not breaking from it we're not trying to greenfield our own definition, and the details are there. So at least that's my two cents on this, and you don't have to get into the capability model that's a later thing we could do a we can respond to the TOC in short order, both with a short form definition and an explanation. And we can move on to the other things because that's what they ultimately asked for. All right, I'll shut up now because I've been rambling for a while. Yes, it's good I agree I mean that's that definitely is the current definition of an operator fluxes definitely an example of something that's kind of you know, in a weird place like it doesn't extend, you know, the Kubernetes API directly I don't deploy like, you know, like the flux helm operator get is a different, different beast. But, and I think that it also like comes down to like you know managing an application from an operator perspective shouldn't be like a one time like install right like, like, like, in using an operator to deploy postgres is different than using an operator to manage the lights to manage postgres running in the cluster and make sure that it like, it continues to work right like, like, monitoring like making changes to parameters that are necessary and things like this like operators for install versus operators for runtime. I was just going to ask in our defining operators to respond to the TOC and to share to people. Do we have to get into the nuances of what the common tasks are. Is that a requirement of providing an explanation. I don't know if like a requirement, I actually I don't think that a requirement is to define the common tasks but to like to like to like define what areas of the life cycle of an application that an operator like is potentially or should be responsible for is it is something that just installs an application and then done and it never touches it again is that does that meet the definition of an operator or not that's a question. If something that just installs an application. So if we go back to let's go back to the definition because I think this is wonderful. The definition says it says includes domain or application specific knowledge to automate common tasks right and so the question is is by something that just installs an application and never touches it again. Is it actually automating common tasks. We consider on and argue whether it is or isn't I would actually argue that it's not because you're not getting into the common tasks. But do we need to answer that question in some form of long form description in order to respond to the TOC on this. Do we have to share Divini any you want to jump in on any any kind of. I think right now we do with how we we we've not written it down so so either we're not being specific enough right in in the exact terms we mean but because I because I do I do agree like is it is it enough for example to for for for definitional like like let's just let's apply the test right to that that definition is I'm going to just I'm first going to pick on pick on Helen but is tiller an operator and because in actually that's a bad one that's wrong. No tillers not an operator and it's not a custom controller anyway. So it's an easy one. Because it's not a controller. Yeah. And it's also not application specific. It's not targeted at something like Postgres to continue my example. It is a more general thing. And so it fails that test as well. Yes. So it's okay. So certain manager. So they're not calling themselves an operator right now under this definition is what we consider certain manager and operator. It doesn't manage an application. So it manages certificates. But it does extend the API. It is a controller. Do we have to answer that before we have a definition like they don't brand themselves that and not all things that are extensions to the Kubernetes API are in fact operators. I agree with that but but our we should be able to apply a litmus test to our own definition before we even internally we don't answer it to the to see but we should we should ask ourselves that like like does it is our is the wording we're using our definition specific enough before we pass the definition so that we don't have to be long for because I don't want to go long form, like if we don't have to. But if we're missing specificity in what we're saying, and too many things in our in our own like gut check before we pass it that's going to cause questions and stuff. Okay, let's assist though. Let's assist them. Um, does the does it extend the Kubernetes API. Well, the answer to that is yes. Right. Um, does it contain application specific knowledge. The question is, so what is the actual application here. Is it their own custom application, which is something that it also manages. Hey guys, I have a good question for me. Yeah. So I'm a new one here. So I'm kind of wrapping my head around. So yeah. My question here because I see both arguments and the old body but the question here seems to be is do we actually have to use the word application because that's the only thing that I see so far that is creating the confusion because when I does have a domain specific software that needs to have some knowledge in order to be operated, but it's not. I wouldn't call it application. Like for example, that's the only word that is creating completion, at least for me, maybe you guys can help. Okay. So, so the original chorus definition said domain or application specific knowledge. And I for one don't want to remove the or application here, because I think for a general audience, that's going to make that example more clear in their minds because they're going to start to ask, what's an application in my case for what I'm doing. And if you say domain or application specific, it kind of zooms in and answers it for most people, but it doesn't preclude the domain part of it. And so the chorus folks really I think cleared that up for us when they originally wrote it. So, no, that's great here. Does the dessert manager do domain or application specific stuff. Yes. Okay. And then are in this one is where maybe the hard one comes into are the the applications or the thing managed. Right. Is it managed by the operator instead of the Kubernetes user. Yes. Right. And so, so I like framing it as a question that can hopefully be answered yes no, and it can kind of be boiled down to those three questions. And maybe we've got to finagle the language a little bit of it. But if we can answer yes no to those and all three are yes, then it's an operator by their definition. Right. How it does it and to what level it does it are things we can debate in essence but it can be boiled down to three yes or no questions, I think. Yeah, but I think that what I'm struggling with, I think we're not in front of the chess here. We don't want to look at components and want to decide necessarily whether they're not an operator or not. And very often the question that I hear from people is, okay, I have built xyz on top of Kubernetes, whatever it is, should, and it's kind of complex to manage, because if it's just a very simple piece of work loads, usually people might not care. Should I build an operator to manage and run the thing or shouldn't I. And would it help me. And user perspective rather than looking at something oh this looks like an operator does this really matter. It's all the one thing I'm looking at it, but at the end of the day. One problem we need to solve as a community is making running workloads on Kubernetes less complex than it is today. And a lot of frameworks have not really done a necessarily great job at that. Like even at some point we just made it more and more complex like help for example help charts did not really make it easier to run stuff, except that you have just to apply 100 but building it doesn't make anything easier. And it doesn't cover certain things. So that's my point here. Who do we want to help. So, so I think there's actually two separate things here. The first is helping people who have that question. And I think that's entirely valid to try to come up with answers for them. But then there's answering the question that was asked to say gap delivery by the to see what is an operator, because what it is, and should I get into one. And then the third thing I would argue from what you just said is, how can I build a toolkit that's useful for people to help them move faster and make it simpler. So there are three separate questions for three different target audiences that each need their own response. And so the first one here was just trying to the to see back before the holiday break asked this question and now we're something like five months later, and they're looking for a response of what an operator is and so what actually need. Yes, there was the question that can was agreed that is part of the working group we want to answer questions that actually help people out there and just move beyond. And I get and I know what this question was asked. I was actually part of this conversation. And it came up as part of the operator have discussion. If you remember. I was talking about like installing applications. So, I think that these three questions actually go well together because if you have a construct there, like an operator, the first question is why does it exist. When you know what it exists and we can define okay what, how should it be, what should constitute this construct, like CDs controllers, whatever. The great one is then the next one. What it is today might be worth this. I guess what I'm arguing for here is the TOC asked for something, and we should probably give them the answer to the thing that they asked for, and then take the other two things that were brought up and look at who the target audience is and then craft something specific for them, because the definition of an operator isn't something that people are creating frameworks probably need to have. Right. And should I use an operator is kind of a separate thing. And should I use an operator is kind of for end users who either want to create one or maybe look at using an existing one, and then somebody who produces an operator is in an entirely different role. And what they need to think about is different than the end users right and so there's different target audiences. I totally disagree here, honestly, but I have never built any product in my life that it did not first thing of what I'm going to use it for and then this feels like we talk about technical constructs that exist on the cloud case Kubernetes like CODs and operators and by the way keep in mind that technically everything we do is cloud native so they should also work outside of Kubernetes while we're not focusing on it right now but I could build like, so even something like the current operator like a file definition and something that has a reconciliation loop running on top of it even with lambda and CNS three bucket conceptually the key question for me is why does the thing exist and why should people be using it and then what falls into it for and then I'm thinking about the technical details. It feels a bit weird just take the technical concept and then later on finding the use case for it. And I'm actually not arguing that I'm actually arguing there's different roles in this whole thing. Okay, and so I'll take helm for an example you brought up helm. And so with helm, it's a package manager right at its heart. It is a package manager and I like to relate it to something like apt. And so with apt right somebody who has domain knowledge of Debbie and base systems and domain knowledge of an application puts together a package and then distributes it and somebody else who doesn't need to know intimate knowledge of those Debbie and base systems or of operating that application can install it and get it up running quickly and use it right it's a great way to share applications and make it easy to install it's why use apt get install all the time on my systems without actually knowing all the intricacies of where files need to go in the binaries and all this stuff. And that's kind of where helm comes from but if you break that down. There's two different roles. There's me as somebody who's producing the package and the knowledge I need and the considerations I need to have. And then there's somebody who's going to be installing it and the role they have where they need to discover the package is be able to evaluate them and install them, but they don't need to know the intricacies. And some people are going to wear both hats. Right. Some people will wear both hats where I'm doing it. We used to use apt where I used to work to manage our own deployment workflows in staging production and things like that and we needed to work both hats. But the common case is you still have these different roles and sort of think about what you produce for those different roles and what's useful for them and not trying to put them all together because you know, then you're starting to mix things up and you've got to pick what's for me and what's not and where do I go into what level of detail, but actually crafting things that help people in the different roles where they're at. I think that would be useful. In our case I've listed to here who's the the operator consumer who's just going to install it and get it up and running. Then there's the person who's producing operators those are kind of two different roles. And then of course in this case because there's an answer from the TOC there's answering that TOC question. And giving them what they asked for as just even a point of process, because I think they're still wanting that but I don't know if there's a to see no there's no to see member here to answer that. But even giving them as a role as somebody who asked for something in us, giving them what they asked for. And so those are kind of the three things that I at least was thinking of how do you give each of those their thing. So, so I'm going to chime in here, especially on that last point or at least to start on that last point is that we can to the letter give the TOC what they asked for or we can give them what they need. And what they may need more than a strict technical definition is they may need. They might really been asking the question of okay help us really define why operators are valuable so when I think about this and I've been listening very very carefully here trying to form some opinions and if they're still not quite formed but the operators are a way of having somebody be able to package up a capability and for a different constituency to be able to consume that capability at the core. That's what an operator is. I like parts of the definition that you drew out from the original core. For example, love the fact they extend the API one. I think that one's pretty important. I so I think that there's elements of that definition, but I tend to also want to back up and say, Why, what are the problems that we're trying to solve with the operator before we start defining what it is so. So I guess I'm lending some support to you a lot. So, let me ask this, are we do we get to define what an operator is, or is it something that is already defined in the market, because we aren't greenfielding here. And I think that's that's one of the things it's not like we get to decide what an operator is operators have been in the market for years. And maybe they need to be described and it need to be written down, but it isn't new. It isn't we're not the creators of operators. I think that, like, that's true. But I think like the goal here is to better define what actually is an operator so that we can kind of put like, like, something that maybe currently called an operator actually doesn't meet the definition of an operator. And therefore, like, as as as a consumer of that operator I don't expect to the same functionality the same services that that thing provides because it's like it's not the same right now right like, I might look at helm and tiller helm v2 and say, that's an operator because it's actually like to me it creates this abstraction around the Kubernetes API so I can just run helm install and helm upgraded to manage my charts which are applications and that's an operator. But like, that's not an operator I think Matt you agreed to that point you shook your head pretty emphatically when Jared mentioned that helm might be an operator. Being able to say look helm, you might think of helm as an operator but it doesn't meet we fit into this bucket of what we what we in this group define as an operator means like you shouldn't expect the operator services and operator functionality and you shouldn't expect as a consumer for it to fit into like other tooling that are built around the operator ecosystem. You know, defining it is definitely necessary here we we we don't get to define like what people are going to create but we do get to define like this label operator that we get that people can kind of like slap on and say like this meets the definition of an operator and that's that's what I think here. And even to the installation like one that I can see sometimes people just use them as better installers to do some extent it just use it to install complex application but like one key aspect of an operator for me is also the reconciliation look like a dynamic piece of it. It's just not a system that simply installs something and then the scare was what happened it actually jacks that that's something happens because it's actually for just doing a cute control apply. Let's go back to like the very basics and I'm just applying a yeah but I don't know whether this thing is even working out. So it is the basic primitive of the platform but I'm not sure whether anything happens. So, yeah, I want to think about it. I think that comes back to the including in the definition that it's like it extends the Kubernetes API and it has an in cluster controller, or I don't know if maybe in cluster might be too, too, too broad there but like, it seems to be the common use case but like a controller which is continually running a reconcile to like to manage that application. So, so the thorough loop here, let's let's take let's go back to our home example. And bring up, I'm going to bring kudo into this right because, because, and my question is, does this have to be a singular holistic unit, because for example, kudo can then start to bring in a reconciliation loop and various day to a helm chart right eventually to a CNAP bundle, everything else. So, is that combination of things that installation of postgres with from a chart with a kudo, you know kudo lifecycle around it. Is that now an operator or is it not because it's not a single controller that also knows about postgres. So, so let's get into this though. So, we'll ask the question with with the chorus one and then maybe debate it right does it extend to the Kubernetes API. All right, does it. Where are my questions. The it now becomes the question. What's what's the it. In the kudo example is domain or application specific knowledge included in kudo. I mean, what is what what's the application is it the application that could that the operator that was written in kudo is or is it the the the kudos like a meta operator right like it actually like is it has the application and the domain specific knowledge of how to like create and run that operator inside the cluster. Jared, is that a fair. Exactly. Exactly. Yeah, it's so. So if I understand it right what you're saying is kudo itself is not an operator, but an operator created with kudo has extends the API and contains the application or domain specific knowledge right. Yes, now that that that said it in some cases it only contains domain specific knowledge right because it's bringing in an external helm chart. Sure. And then you've got to ask our common tasks being accomplished. Right. And their language was to automate common tasks. That's the language in the chorus definition. And so would common tasks be done. And so in this case a common task might be will say Postgres install upgrade delete. You might do backups. Can those common tasks be accomplished defining common tasks and that's also what you have the capability model. That's right now. More specific what the common task is because actually back to the previous point of certificate management when you get certificate is a common task. Updating a secret is a common task. Updating routing rules is a common task. And the common tasks are going to be different per application or domain area. Right. I think that's one of the things we just caught because doing cert manager is going to have in certificate management is going to be an entirely different set of common tasks from something like Postgres. I hadn't thought of that before. That's why I think defining what a common task at least by example is and I think that's what the capability model did in the past way beyond that with like sales managing and so forth but defining that what is a common task at least that we have for community service. So we could give examples of common tasks but I don't think we can define them because to define the means we need to know all the areas and certificate cert manager or yeah. And Postgres operators are going to have you know database operator they're going to have different sets of common tasks. And I'm sure there's so many different applications out there with so many different common tasks that it's probably not useful for us to define the common tasks because we're not going to know everything to be able to define everything but providing examples of common tasks to illustrate them for people may be very useful. Yeah I don't think that we're going to be able to like provide you know an exhaustive list of every possible operator an operator could could meet right because like to your point like every applications a little bit different. There's a common set of common tasks around like application lifecycle management which like an operator doesn't have to necessarily like implement but you know kudo when I write an engine X operator using kudo like it may be that that operator is just installing and upgrading engine X inside the cluster. Does that still meet the But it's also going to if you break out of the application as we talked about earlier to the domain, you may not have the simple install process. Right. And I think cert manager brought up is a fantastic example of that. Are you really installing an instance of an application. It's more domain area that application and so do those common tasks hold when you break out of the application model into the domain model. Yeah, I'm not sure that that that's your application need a valid search to be there or if you're using let's encrypt that's a whether that's encrypt operator which would actually make a lot of sense by the way to have a let's encrypt operator that would automatically with you my certificate. Matt though to go to your, your point to like I mean the CoroS original CoroS definitions that domain or application specific knowledge not domain and application specific knowledge so like in this case like I totally agree with you there's a very different definition between domain and application and like this engine X kudo example is like it's kind of like it's not a very full featured operator but it still meets the definition there. Let me ask this to actually create a definition. Do we need to define this because I know we could take a long time defining and thinking through all these things in order to create that that definition is it useful for us to go down all of these roads or just to consider and give some examples of common tasks and move on to some of the other things like the role of as a consumer of an operator should I use one. Right and move on to something that that targets that role and provides them with the contextual information they need to say okay, should I bother with an operator in this particular case, how can I myself figure out if I should as a consumer of them, and that may be. It may be useful to just switch gears into that instead of spending lots of time going down this whole. I think the answer to that question about whether we should have to whether we should include that definition kind of comes back to like should is should the definition of operator be like this really wide umbrella that covers like everything that like sits inside the Kubernetes cluster that manages other applications. Not like it's not a final application or should it be a very narrowly targeted like very specific thing that says, like it has to extend the Kubernetes API has to include domain or specific knowledge. Like the original definition says it has to be stateful components that doesn't feel like, I think we, most people agree that that could probably get removed. And does it have to have an in cluster reconcile controller loop that's running to like manage the lifecycle or instead of just a one time process of like managing these, like if we if we start with saying like is that the definition of an operator that's that's you know, kind of relatively broad but like it excludes random things. I mean, if I take out stateful stuff from theirs, it seems pretty still solid to me, because if I go and start extending it further. Then you have a hard time of saying I've got a random controller and some CRDs, and it doesn't do anything that's domain or application specific. Is it now an operator. I actually agree. I think that's a good starting point to the definition. I think that like, the only one that I have some doubt still about personally is like an in cluster controller reconcile loop is that a requirement to be an operator because like as you know could control extensions are being like more and more like, why be adopted and you're seeing those more is it possible that you could actually have something that runs as an operator that's invoked through a control plug in as opposed to like running inside the cluster. So is in cluster required as the reconciling. Reconciling cluster. Yes. Reconciling could be out of cluster, but the reconciler needs to be in the cluster. I personally think that it has to have a reconciler. And there has to be some reconciliation. I think this is a great topic to dig into and so so let's get to the heart of this kubernetes is a declarative model right you declare what you want and then the controller takes that in attempts to make it so and provide status on that situation. Right. And so if you move it out of cluster. Right, then where is the thing that looks for the changes that is reconciling and making the necessary changes to say, Oh, this no longer matches. Now I'm going to update in kubernetes that tends to be the controller whether it's custom controller whatnot, looking at events. If you've got something outside of the cluster. It is no longer watching for events it's no longer watching for changes on an event loop that does that. And so, in many ways you've broken. Oh, bring up one example where this is not the case actually please this is not this is not an operator but what we do for example, or you can look at his monitoring system that have run for automation enabled. They're not running in the cluster. None of these components does, but we look for example and then our goal more or less and we don't use any of these components but we will a lot of what an operator does. We look at response times of an application of the service when these response times go above a certain threshold. We automatically scale up that service or if one for their behavior with disabled feature flags. So we do a lot of what an operator does. We can do it directly with a cube control apply. So it depends on how whether the service is doing what we want to do going beyond just the instances running, but technically there's no component running inside the cluster. And is there an extension of the Kubernetes API and married also. No, I could. Well, we have, we have built it with extensions to the API. I can just have a monitoring system colon and simple script that doesn't keep control apply. And it's a question. Do you actually think that that's an operator? Do you want to call that an operator or not? I don't need to call an operator. It uses the operator pattern. That's the interesting thing for what it's done, but it's not a operator. Jared, you're first. Okay, actually, no, I'm going to, I'm going to, I'm going to throw a wrench in so you go first. Okay, well, what I was going to say is, is this application or domain specific? I was going to ask that question. It is application and domain specific in both sides as we have to make application specific as those. And we have domains, the application specific actions like this, enabling and enabling feature flags scaling things up and down. So it is application specific actually the only one who can define it is somebody who knows that application. So the system is targeted at a specific application like Postgres and not applications in general. So I can't monitor some random application and say, look at the metrics for this and scale it. It's a general thing, right? Or is it a specific to an application or domain like certificate management? I would always have to define this very example where I'm using it for dynamically mentioning managing deployments based on monitoring data. It would always be application specific what I want to do it under certain cases. Maybe it goes beyond the scaling stuff up to get if it gets so I could say this is not application specific. So, so it's it's to the application specificity, not to the type specificity like you're not monitoring all deployments and scaling them. It's only deployments and you can relate the type of application running as the deployment and then do that. Yeah, we will have to know what it is because otherwise we wouldn't know the actions to take in. Okay, you're essentially running a controller, but you're running it out of cluster rather than in cluster is what you're saying. Yeah, and they have a reconciled loop as I'm monitoring and looking at the data. So I'm fulfilling all almost all requirements at a conceptual level, but not in the implementation level and I'm not claiming it's supposed to be an operator don't get me wrong. I'm just saying I'm implementing all the concepts we talked about. Conceptually just my implementation is different. Okay, I would like to point out one thing before I pass it off here real quick is operators become an amazing branding thing. And so I know lots of people want to put things into operators. I think it's useful to say what it is and what it isn't. But I also don't want to hope for more things to be operators to somehow fit into the branding bucket as part of this whole thing that just occurred to me. There's this desire to say, ooh, my thing's an operator to to use it as a branding and a thought and there's so many useful things that are not operators, we shouldn't try to go with that branding bandwagon, but that's me. I'll shut up with my soapbox. All right. Okay, I'm going to try to throw a quick quick wrench into this because I agree with what you're saying but you know there's something here that has a lot more possibilities to it, potentially, and it is okay well. So when we say reconciler right and controller what we really mean is a process that is watching again point that detects a, you know, is detects a level change, it compares to things in advance the state right like that's all reconciler is. And we have a baked in assumption at the moment that that is coming from that whatever the end points of whatever you're watching those resources. Now, let's say, and getting to marks like like running it from kubectl point or running it from your command line. If you have all the controller logic baked into a CLI tool that did all the exact same things, except the end user was the one say kicking off and there's other ways to do this of course but like, if I'm just hitting up enter up enter up enter on my on my computer over and over and over again, running one run of the controller loop control loop right event loop. Is that an operator like like it's doing all those things. And there's there's there's, you know, some some things I've been thinking on and others here like they've been thinking about like where these operators like semantics could be very useful. Without being like in a event driven like we're event loop right like not being bound by that event loop and always running. Yeah, I mean I agree I also really quick point out like we're like at time for like what this meeting was scheduled for. So, like, it's it's an interesting conversation there's a lot of a lot of opinions it's a good conversation. Jared I totally agree with that point though like and I don't have an answer for you I think like that's just something that like I do think we need to define that to your point like we need to define like, I don't think like, we want to say like here's this like, it's a branding opportunity and what what might potentially be included in an operator there's there's there may be stuff that gets carved off and gets a different label and gets a different term that has its own working group and its own sake over time and like maybe the kubectl plugins is not actually an operator and in cluster control reconcile loops are actually a requirement. I think like part of our goal here should be to make that that decision though. And I guess I'll just leave when I think about what we should do and what we can do and what we're scoped to do. I was actually reminded that this all falls under the TOC and I just dropped a link into the TOC scope. Right. And so you'll find me being a little careful in coming up with things like the TOC isn't scoped with creating terms, but we can document what's already there. And we can create white papers that are useful for people but we don't get to create whole categories. And I don't really think that they're scoped with that and so I'm just keeping this in mind and so when you all wonder why I come with the opinions I come with in the direction. It's really because I'm attempting to stay in scope and on direction. You'll find that a lot with me. And so at least that it will express why I come at it the way I do. I think that's a great link to kind of kind of like limit the scope of what we're trying to do when we define it so. Well, so let's wrap it up. What's our what's our actions between now and two weeks to work in this talk try to sort of pair this down, get to a definition. And Mark, what do you think communication here or in the mailing list. I mean, I think. Can you define what here is like wait for two weeks until the next next meeting or the mailing list would be like more ad hoc and like in continuous right. Yeah, exactly like what do we what do we want to kick this off with in the next two weeks here. Yeah, I mean I think we should continue to work on the on the on the document I think you know like everybody has it it's like this is the first topic here like we can even edit it we can make comments on it and the mailing list is there to like discuss stuff but like I mean I'm, but I think all of us are like, pretty, pretty excited and have some strong opinions about it so like let's discuss them in that document and like if we need to we can go we can go to the mailing list to but there's just until the next two week meeting either. So I have one question here I wrote up another document just I was trying to figure it out starting with the definition and then explanation and test it's radically different and I didn't want to like overwrite which you already had. I can send that out to the mailing list or otherwise share it. But it because it's so different in structure. I didn't want to like drop it in and go crazy on your document. So I wasn't sure what to do but I'll share it to the mailing list, and then we can take it from there. This was me just trying to work through it and pick it apart with details on each thing. But I don't want to mess with yours which is the reason I'm not going to just drop it in. It's like two and a half pages long. I mean I've read through the document you sent it out this morning it's it's good like I mean I think also it probably worth adding a link to the other doc to it there's like an alternative like suggested reading for people who are reading that one doc is like, you know, another approach to this. Yeah, and I was just trying to, I wanted a logic reason based structure through my thinking on this which is why I put it together and tests. So that was my purpose because I hadn't really thought through it prior to writing that up writing sometimes gives me the ability to think through my structure and thoughts. But yeah. Great. Awesome. Any other thoughts anyone. Yeah, and maybe having like everybody's opinion on like the different capabilities that we have in there would be great collection until next time because then we have something to discuss. So I usually like meetings where we have something that we can prep for. Like we have now a lot of things that we want to have in there and we can have at least from the people who are here plus the ones on the mailing list. What do you consider important. I think we did this. I would be important to consider this year the important if not point out you could even put this into a Google form and see what comes out of it. Exactly. I think this meeting came did a lot of really good discovery and kind of opened up some questions that we can like now have like more more deeper dives into those questions and hopefully you know in the next two in two weeks from now when we get back together for a meeting will I have a very clear agenda with some questions that we should have some more everybody set a little bit of chance to kind of rock and read and understand so. Okay. All right, well let's wrap up for now. Thanks everybody for attending will send the like notes out the agenda is there in the in the zoom recording will go up. Thank you. Thanks. Thanks. Thanks.