 Hello. Hello everyone. Let's give people a couple more minutes to join here. In the meantime, obviously, as always, please add yourself to the meeting doc as we're waiting. So I just posted the link into the chat in case you need it. Okay, so now we are five minutes in. So I assume that a lot of people are preparing their cube contacts as we speak. As the recordings will be ready. Also, let us get through the agenda here quickly today. And we can obviously finish up earlier. Oh, yeah, it's one. Ashish is wearing the cube con t-shirt already getting himself into the mood there. I was looking at my shelf and said, oh, this is the one that I should wear today. Yeah, okay. So for today, we have three points on the agenda here. Number one, that I might move back just a quick introduction update here on Potato Head. Then the operator working group update that Thomas will present and waypoint. I don't know who added this to the agenda. Okay, Matthew did it fine. So, yeah, let me just very quickly start with the Potato Head piece. This is going to be a quick one. So during one of the last meetings, we actually discussed that we started with a small app delivery demo. And for my cube contact that we do about the sick, it was actually a good way to get started on the demo. So the demo doesn't do anything great so far. However, you can find it here still under my name and app delivery. I'm just pasting this one in here as well. Oops, sorry. So what did I do here? Just very briefly, I created a very simple demo application. It's more as a go-based web server that is available in three different versions. And it just says hello world and returns the version. So nothing really special. The idea was to keep the app really small and it will obviously evolve as we put more use cases in there. But that's where it is for the time being. The more interesting things though, so actually you can have a look at it. If you go into that one here, just test the Docker files for these three versions and you have a very simplistic Docker server that just does nothing else than just return some static content and a hello world with the version number based on a startup parameter it gets. And more interesting thing though, what we wanted to have, we wanted to showcase different projects. If you go into the delivery folder, you will find a number of different approaches in there on how you can actually deploy this application or deliver this application. We have standard Kubernetes manifest. We have using Helm charts. There is also a Helm operator that was built with the operator framework in there. There's also a description on how to use it with flux and there's also a description on how to use it with Argo CD and there's also a version for Argo CD rollout that releases the whole thing and as a canary release. So this is again, as it indicates over here, it's very early stage. It's just that first collection. I just wanted us to have something to get this kick started. Also, if you don't like the name, I'm open for suggestions. I was just thinking of potato hat because like you can put stuff together and the idea is that eventually we have individual services for the individual pieces that you can put on the potato hat. So there will be a hat service and ear service and you can have different versions. Some might be stateful sets. Some might be external components that we're going to pull in there. But yeah, what you're getting, you're getting a simple Go server. You get a multi-stage Docker build file that builds your Docker files. I put them right now in my current Docker repository. Eventually, you might think moving it somewhere else, obviously. And then you have these descriptions in here of what you can do with it. And there's like, I would say the direct deployment. There is just a direct deployment and there's a Helm chart with two variables. But then there's also a description in there. Okay, that's a bad one because that's not fully done yet. I think here's a bit more. Just get me one that I have actually put something in there. I think the Helm-based one has something in there. Yeah, just some basic description. That's actually, yeah, the Helm-based operator. How you can build it, how you can use it, how you can play around with it. So the idea is that we'd like to take this basic application as we discussed. It has all of these capabilities and you can more or less than build different scenarios on top. Obviously you can also add chaos engineering in there, a lot of different things. What's not yet done is the CNAP version with Porter. That's still currently working progress. Thomas and I were working on this one right now. We kind of got it working, but we did not yet get it working in a platform-independent way. So it's still working progress. This one just says flux is not available. It actually is available now. There's also a flux version in there as well. And we use this now as a basis also for the CQube contact. The idea is we had like all of this, ah, the landscape is so complicated. What can I do with it? And just walk through it. And it's also follows that conversation on the mailing list. Obviously the app is very basic. We have to build more around it. We can build more complex scenarios, but I think it's a good starting point. And I deliberately kept the app small as well because one of the complaints or the limitations I see with some people, I want to run it locally. And if you run like a Cannery release with multiple, it's a higher replica sets of something like the hipster shop, it consumes a lot of resources. So you have to run your own cluster, running it locally in a smaller mini-cube environment is kind of hard here. So that's just the initial update on this one here. As you've seen, I'm not totally done yet on the documentation bits and pieces. Luckily, right now, only the recording for CubeCon has to work. The final documentation needs to be done once this is out by CubeCon. Again, if you have scenarios, if you want to contribute to it or do anything about it, just yeah, feel free to say it. Matt, you want to say something? Yeah, I have a few things. When are you doing the recording for CubeCon? Tomorrow or on Friday? Okay. Then I noticed the helm chart here is incredibly basic, like rudimentary basic. If I throw together a pull request that puts together one that like follows best practices and kind of has the structure we recommend. Okay, I can probably do that later today. So you've got something. Then what about a helm chart repository? Did you just have the chart? Did you want to show that off or are you intentionally? So I think for the time being, we kept it like super, super simple. So I'm more or less focused together over the weekend because I wanted to have something available. I think if we can have this grow, I just want to like really show the basics for the CubeCon session, we can evolve it and have the repository in there. I also want to eventually go further like having them the chart signed and everything. So as we progress there, that there should be more. I just wanted to kick it off that we have something to start from. And just starting with hipster shops seemed a bit of an overkill. But yeah, I totally appreciate any support. And yeah, I was about to move it over to the CNC. I said, right now I just put it under my own organization. So Amy, this is maybe something we can figure out how we can move this into a repo that's not my personal one. I would just recommend it. I have a designer over here who gets me a logo because right now the logo is just took it off Amazon from Martel and just put the Kubernetes logo on top. I think that is not 100% legal what I did here. But I think nobody's going to do anything. So that this will be removed as well. And I agree the Helmholtz is like the very basic version of it. So whatever you have to add, obviously you have a lot of great ideas here. Just for free to change it to whatever you want. Certainly. I'll start with a basic Helm chart. And then if we've got time, I can help with a repository or something like that too. Even served up using GitHub Pages. But I'll start with a basic chart that's that or a chart that adds a little bit more. Okay. Yeah. And obviously going forward, I also talked to Harry and some folks over here. We will obviously add a couple of small services. And I just wanted to do something that's not like the standard. This is your e-commerce application where you can buy stuff part. And having the idea of being able to configure a potato hat like with microservices and you serve the ears, you serve the hats, that might be something a bit more fun. And you can eventually even build some, some fun gimmicks around it. Just as a native speaker, I'm not offending anybody by calling it potato hat. No, no, this is a, I like the name. A lot of people who grew up with those will get a kick out of it. Okay. Yeah. But yeah, thanks Matt for your help. And yeah, just feel free to file the PR on it and I'll happily accept. Okay. That's it more or less on that repo and we will obviously continue work on this one. Okay. Then I pass over, I think Thomas, you had the operator. Okay. Yes. I talked to artist regarding the regarding the operator working group. And we want to make progress on this working group. So we decided that it could be a good idea to take this document step by step and to define what an operator is and not what it not is. And also leave out all the discussions of what are competing products or products nearby. I think all of these topics are things we could discuss when we have a first draft of the document and when we find out that there is something we see. So I sat down together with some people from the working group here and we talked a bit about what an operator could be. So let me share this group now. I found it. So, yes. And the result... That's a little bit small maybe for some people. It's better now. Okay. So we talked about it in Monday and today I've written down the results and tried to sum up everything which was in the definition of an operator until now and the things we found out on Monday. We tried to get a bit of a rough definition. Afterwards, I tried to describe the word. So what is in control or what are custom resources? What is a custom resource definition and how does such a custom resource look like? And yes, afterwards, what is a reconcilation, reconciled loop and so on. Afterwards, we found out some use cases for an operator. So you need an operator to install, upgrade, configure, reconfigure and so on in application. So I also tried to add this to the document and I tried to put in some graphics about the operations of an operator. So an operator watches and compares external events, current state and custom resources and gets it to the desired state and knows how it gets to the desired state. So if you want to update from version 0.1 to 0.2 an operator has to know how this works. So yes, that's wrapped up. I think everyone of you can read it. What would be very cool if everyone of you could read this and we could discuss this in the document. But please propose solutions and not only comments. Yes, and afterwards, we can also talk about it and change it, isn't it? So the next, yes. One thing that just struck me, can you scroll back up to the beginning real quick? Because what I see is a lot of how an operator works but not so much what an operator is. And that's what I was, yeah. So me as an end user, right? Somebody approaching this whole thing, what is an operator? Like from this, I understand how it works but I don't really understand fundamentally what is it at its core, right? It talks about the mechanisms and Kubernetes parlance but it doesn't base down what I am into a simple definition. And that's what I'm not seeing here. And so that's just one thing. I'll add a comment on it to the doc. Could somebody drop a link to the doc into a chat or into the thing? I'm just digging around for it in the different documents and I haven't found it. There's a link in the current speak open name. In the last meeting. From the last meeting? Yes. The last meeting agenda has a link to an issue but that was it. Oh, from the last meeting of this one. There is... Okay, I see it. Yep. All right. I see it down there. Thank you. So please feel free to comment on it, make proposals and so on. And I think we'll get something really cool here. But a lot of this, so when you think target audience this is a target audience to somebody who's going to build it and probably needs a foundation in the Kubernetes parts already knows some of the Kubernetes parts. And so it's somebody in the Kubernetes silo who's navigating Kubernetes who could read this and parse it apart. And even they are going to understand what's fundamentally difference between this from other types of controllers and CRDs. Can we use CRDs and a controller together and have it not be an operator? Like those kinds of... Like what is it at its essence that makes it an operator apart from something else isn't here. And if you're not in the Kubernetes silo this doesn't tell you what it is either. And so I'll make some comments to that. But that's kind of what I noticed about the definition. Okay. Yes, afterwards I think it would be cool if you discuss this and so on. And what I would take as an example is to, I think in the document there's something like a material model. And what I want to do is to find out which things an operator needs to get to this maturity level. And eventually get examples of how such an operator could look like. So... Just one comment here. Before we discuss to not call it maturity model because not one operator is more mature than another one because it can do more. That's why I think even the Reddit documentation switch to stages. Okay. It doesn't mean that an operator has to be able to do a backup that it's more mature than somebody that does install on updates. Just as a minor comment because people didn't like the idea of having it like maturity. It's like you always want to achieve the highest maturity. I only took this from here out or I kept using the model and matured model. Yes, but we'll change it to future. Yes, and that's currently all the work we did on the end of the working group. So if anyone is interested to contribute, currently I'm sending out the meeting for every week. And yes, we're talking about it and trying to get some discussion into this topic. So please can you feel the contact with the community? Yes, that's from our side. And I see we have time to have another meeting on this one too to move this forward, right? Yes. So next one will be next Tuesdays, Mondays, Yeah, I think it's, I'd really like to see this document moving forward. This has been around for quite a while now. I know that I appreciate taking the lead on this one and assuming we have something to share soon. And we still have the idea, right? To have like one example. Okay, this is how you could do things like in an abstract way, like not the implementation dependent. Like if you want to do an install, that's what something could look like. And also if you want to do a backup on a file layer, we could also have an example of how this could look like and how this works. So this would be my point for the next week, I think. Okay, good. Yeah, maybe also share it on the mailing list so we don't have that many people joining today but also give them a chance to read it through and I guess you also tell them by when you want to do the feedback. So I realized that obviously a lot of people, a lot of more people are reading the mailing lists and commanding on the mailing list that those who are necessarily joining here. That was my take over here. Okay, I think the next agenda item is already Waypoint. Matt, what do you want to tell us about Waypoint? Well, so Waypoint, does everybody know what Waypoint is here? No, okay. So Waypoint and I dropped a link in is a new project by Hashicorp that's a pass but they're not calling it a pass but in their session they called it a pass and it's a new thing that runs on Kubernetes. I understand it, right? It's from Hashicorp but a number of the people are old Herokuers and it's one of those things that is definitely an app delivery thing now. I'm sure Hashicorp, because they never give anything up to the CNCF isn't looking to donate it to the CNCF but the project, the philosophy and what they're building here very much has to do with app delivery. And so it just came out, was it earlier this week or last week? I've already lost track of the days and I thought it would be something worth just exploring and looking at here. Now, I can't walk through it yet because I haven't stood it up and taken it through its courses yet. That's what I plan on doing the rest of this or part of this week. But it is one of those things that I think's worth us looking at and who the audience is and understanding. It would be a great exploratory point and it's a new project too. So, I mean, I can try and pick it apart and try and do a demo next week unless there's somebody or next time unless there's somebody who's better at it but I think it's something we should look at, explore and understand. Yeah, we could also ask somebody from Hashicorp whether they wanted to probably demo it. Not that I don't believe that you could do it but I think- No, they would do a much better job. I think they can push decision in the way it is. And yeah, we do want to invite projects. I think it's a good idea to have projects present and we try to do it more and more even if they don't want to necessarily become a CCF project. I think that's totally fine. And the person who did the most is Mitchell, the CTO of Hashicorp. I don't know if he's gonna be up for coming but he might be. Other than that, everybody else had FARC. Wow, how did he write a lot of that? So, I don't know, does anybody know anybody who's worked on this to do this? I can poke Mitchell. I haven't talked to him in a long time but I can poke him and see if he wants to come. Other than that, I'm not sure who else would be good to invite and I don't know the rest. Well, yeah, I mean, if you can poke him or otherwise I can reach out to some people on the, who I know and I think that doesn't know people at the Hashicorp site as well. They will definitely have somebody who's willing to demo. I'm pretty sure about that. Yeah, yeah. Okay. Ooh, I just thought of somebody else I can hit up. Okay, I can try to track down a couple of people and see if I can find anybody who'd be willing to come and demo for us. But I really think exploring the users and how it works with Kubernetes and what it means would be enlightening. Hey, fuck. That's all I wanted to bring up. Good point. Let's reach out to them and try to get them on to the next meeting. Okay. I'm not very careful to not schedule something for any meeting that's going to be in the KubeCon week right now. Do we have a meeting in the week of KubeCon? I don't think so, but I also don't know. Let me check. So the next one is definitely before KubeCon. Next one, because it's in two weeks from now, it's at the next one will be November 4th. Oh, that's an interesting date, by the way. It is? What's November 4th? Isn't the US, isn't that the day after the election? Oh, that's two days up. Oh, yes. Come on, American. You're right. November 4th, the day after the election. You're right. You are right. And that you do have a meeting on November 18th. And we can certainly keep that if you all have like an actual scheduled presentation. We try to be able to cancel all the sick meetings during the time of the KubeCon virtual stuff going on. But... Honestly, I would probably cancel it. I think people will be full with KubeCon related work. And I think that because looking at the agenda right now, things we're working on is like, I started to work on a demo application. We have the operator documents. They're looking into project presentations. The landscape that Harry was kicking off would be another action. I think nobody during KubeCon week is like really that receptive for these topics. I'd rather cancel that one and then move it to... And then let's skip over for one weekend and have it the next meeting. I think that makes more sense. Yeah, that then means that your next meeting is going to be December 2nd. So you'll have one on November 4th and then December 2nd. That gets us pretty close to holiday season already. Exactly. Dates and calendars, you know, that sort of thing. All right. I was just going to say, I just updated the agenda so that the 18th is listed as being canceled. Just so it's on there and recorded. So if somebody does jump into this looking, somebody should cancel the calendar. Invite to. Yes, I think... I will take care of it. All good. Okay, sounds good. I think you don't have anything else on the agenda unless anybody wants to bring up something that we can give people 50 minutes back of their time. I have one question. This is Ashish. So I know that, you know, early when we started this group, we talked about application definition. What does an application means in Kubernetes standpoint? And I actually missed quite a few meetings in between and I'm just wondering, did we settle on one definition or is it something that is not our responsibility? I think we can't really set on it. We put it in there. We had some project. Harry, did we have OEM presented? I think that's the closest maybe to like really application definition. We could also argue we have an application definition in Helm as well. But we don't really keep like any specific work off. I think we had some projects obviously present on a number of topics. Yeah, on the Kubernetes side, we've, it's hard to say what's an application and what's a workload and what's an application made up of other applications. It's really hard to define. Kubernetes SIG apps has long kind of stayed away from defining what an application is because it's difficult to define in some kind of way that's easy to validate, right? And so we've kind of stuck with workloads and generic terms. There is the application CRD and controller which doesn't so much define it but gives you lots of flexibility in what you want it to be. It still doesn't define it but maybe goes a step further. But I don't know that that's a very, very, very hard thing and will probably be debated by people. And so keeping it as a loose term is probably the easiest way to go. Yeah, so the way I see it right now and the way I want to help you play is that at the end of the day, you have to create something for a Kubernetes-based application that Kubernetes understands which means you have to create obviously that the workloads which don't contain everything especially when it comes more to like a domain logic type of approach. There are some projects who are trying to do something in that space. And that does, I think one of the reasons why I wanted to kick off this work on like the demo application because then we can think, okay, how can we define it? Like what do we all have to ship with the thing? Like what do you all need to have in that application? How do you define the dependencies in there? Like one example for me is how do I define it? One service has a dependency, a runtime dependency on another one. Service A wants to call service B. Is that problem we want to call it the app space or is it more at a tracing or observability problem? For me, it's, yeah. I mean, the tracing problem is obviously solved by the open telemetry, but they do it after the fact. So yeah, and some of this is gonna get up with how you employ your application, right? Say you've got a dependency on Postgres, right? Are you using Postgres as a service? Are you running your own Postgres? How are you doing it? And then, are you using GitOps? Are you that combined with Helm charts, using static files? Are you using some other system on top of that? I know there's even still people who use Terraform with some of this stuff. And we'll go ahead and tell their AWS or somebody, hey, I need Postgres and then inject that into something else. There's a bunch of different ways people do this. And do we wanna give just one example of doing it? How far into it do we wanna go, right? And what is that example you wanna use as a data store or something else that you'd wanna do as a dependency? Like how are you thinking about that? Are you thinking about a common one you can get as a SaaS or something that fits in this package? What are you thinking? All right, okay. I mean, I think just having like a demo app but at least like it's don't have Postgres dependency. I think it doesn't seem much dependent like it lives inside of the cluster, outside of the cluster. But that's also what I eventually want to do, like adding more and more use cases. And I think we won't be able to say like, this is the way how you define your application. And the best we can do is like these are five ways what you could have done from like writing all of your manifests and maybe having a Python script running across your manifests which might not be that smart, like having a Helm chart using or you say, well, you want to have that rollout flexibility in there by using our rollouts. That's kind of what I tried to start with this example. I think it's more by examples when that we're not here to tell people how to write their application and we're doing it different ways, what they could do and which tools they could use and they should pick and choose what fits their needs best. And maybe along the lines, we find a way that's more convenient than another one for most people. Sure. And I think, but an outside one like a SAS, like a database is an easy one. So if I'm thinking Helm, you might set a dependency on a Postgres chart and that's only if it's enabled. Otherwise, you pass in your credential or your posted one, your password database that information and your app then uses that instead of one. And so you've got two choices depending on what you pass into your Helm chart. One case it pulls down into the uses of dependency and the other case it uses a SAS. And that's up to you at a runtime configuration and that's just documented and explained. And then you've got two choices and how do you distribute it? And that's all the way I wanted to bring it in. Just show people this is how you would do it with Helm. This is like another way you could do it. But I think that's also why I wanted to get the example to be a bit more complex than it is right now, obviously, but we had to start somewhere and then just show what works best for people and show them how you can learn by example. And that's also why I wanted to structure the example differently because if you look at the standard tips to shop example, it focuses more on how you can use different programming languages and bring them all together like it focuses more than microservice side of the house. And obviously there is Kubernetes manifest. There are Helm charts for all of it, but it's okay, this is a way how you can get it out there and deploy but it doesn't show like five or six of different ways or how you can use different projects for it. There was not so much in the focus there and this is also the difference what I see with Potato Head was like a hipster shop. I don't care so much what the application does and then I can write in five different languages and build it. Here's just a number of images and this is how I can structure it to gather and build something that's kind of interesting and solves typical problems out there. So that's, but yeah, I think that might take us like one step closer by giving people opportunities to do things in different ways and having good descriptions. Yeah, we should just try to make sure that each way is documented and done well so that somebody who comes in to look at it can walk away understanding, not just seeing an example but understanding how it works and how it goes together and why things are done a certain way so they can make wise decisions on their own walking forward. Yeah, that's also why I think there's for app delivery people that want to reach out to like other projects where they want to then provide something but currently we have no service mesh configurations in there that would make the thing also more complex or say an additional things on top of it or we have no like policies in there or anything people might throw in more and more as we go and I just agree that you should actually start from scratch and understand what you're actually doing there. I just wanted to kick it off and have something there and firstly I picked the examples that I have not yet written. I think that that's the best we can go people how they can use different projects and experiment with them and ideally have for them something that they can get there and trying it that ideally, I mean, it's almost like you're trying to get like the perfect polar or a sweatshirt you're trying three or four different ways and then you see which one fits you best for the application that you're running. Yeah, I really like the way how this is done here. I really like the way how this is done here and I think you have an easy way like testing out like six or seven projects for app delivery. I find kind of convenient because you just learn a lot when you start to understand concepts and how they fit together. I think it's not the perfect answer but I think as we ideally will see more people contributing it can grow. I think it depends on all of us to make this work but I think it would be hard to just say this is how you define an application. We might end up with a lot of different opinions. I mean, that's probably the reason I asked that because I've did some experimentation on the space and based on some questions that I got from people and I saw that there's no concrete answer. And it's also kind of hard because it would always mean you have to learn in something new again on top. Well, if you concentrate on what's useful coming up with a definition of an application doesn't mean it's necessarily useful for somebody who's got to run something in it. How do I take the technologies in front of me and understand them and pick the right ones and choose it in order to run it? That's a useful thing. Getting into the semantics of what is an application versus what isn't versus an application of applications isn't necessarily useful to a customer or end user or anything and how they're going to know about doing something. It ends up being a semantic conversation. And so that's why I would concentrate more on how do you use these technologies in different situations well because somebody can walk away with that and do something with it. Yeah, even thinking like having like fun examples that I didn't have time to implement but I can say, well, I'm using GitOps but I also want to use an operator. You can actually use GitOps and an operator together and like building in an example where I'm using GitOps to update the CUD of the operator. As obviously hundreds of different ways to do certain things. And as we've always, we can build like really fun examples that allow people to experiment. But I agree, like defining the semantics doesn't help anybody, okay, like this is a, what I'm saying, this is an application which right now is already simplistic obviously that has like all the characteristics we see in our, in a typical application by like having like secrets by having multiple services and multiple versions. So party dependencies, blah, blah, blah. And this is how you can like ship it how you can like define all of these dependencies and how you can handle it. And there's like five different ways and pick whatever you like best. And if you come up with another opinion, feel free to, or another option feel free to share it. I think that's, that would already be a like a kind of progress because right now everything. Most, that's with that way. Most projects focus on building an application to showcase the capabilities, which makes a lot of sense. But we are more as creating the problem up front to then see how those projects solve the specific problem. Usually you show like how what you can do in your project and that's how you build your demo application. Now we kind of like bring applications like these are like the seven problems that people usually have when shipping it. This is how you solve it in different technologies and where do they help you and where can they help you? I think that's, we may not think like rather than defining like what is an application like can we agree that this, that's the thing that we're deploying here has all the characteristics we usually see in an application or most of it and then show people how they can deliver it, how they can update it, how they can manage it. So I think that might be the more helpful thing here. Okay. One another question is you use the word microservices when you said, when we are explaining how people to use application delivery using microservices. Does it mean that we are taking the serverless or that particular stream out of the scope altogether or it just that we're starting with microservices and eventually we will have any workload that we can put in Kubernetes? I just wanted to start somewhere. And having something that runs in container that I just now called a microservice I think is the easiest thing to do. I was if we can move it further to serverless and I think eventually we should and but usually when you deploy serverless workflow you have to deploy all the underlying serverless infrastructure as well to run your serverless workflows. That's correct. I think that's probably another major undertaking that we'll have to use if there are tools or any other capabilities that we can use for that as well. But it's a lot depending on the platform, the whatever the serverless platform of choice that we'll be using for that specific deployment. But I'm not excluding it. I was just like, as you can see I just started with seven lines of code. Okay. That was the whole idea here. That's why it's a microservice because it's really micro. All right. I think we are pretty much done for today. Any last words before we end the meeting? All right. Then see everybody again in two weeks for now. Bye.