 Hello. Hello. Hello, everyone. Hello. It's people about five minutes to join in here. We're in those five minutes. I have the meeting dog already open. So please add yourself to the meeting dog on the agenda. Obviously, Operator Working Group provides an update today, so I'll pass on to you immediately. Flexing the PR. I brought it up yesterday in the TOC meeting. So just that, you know, it's, I've seen the issue that you want to move to incubation, but the official call to start the due diligence test has to come from the TOC, so I informed them yesterday and expected they tell us that we should start working on it. If you want to accelerate things, obviously we can share the due diligence documents that we have been using in the past review. One last item that's not really right, that's just right because usually you do that very twice here. Obviously it's work on the give-ups working group. I think you also have Cornelia here, that's great. Okay, so I would propose we keep the last one will be most likely a longer discussions. Let's try to keep presentations to 10 minutes. There's plenty of times for the individual topics, and then I pass over to the Operator Working Group. After I figured out where my student, so I can stop sharing, which I can't right now. This is inconvenient. Sorry, here we go. Sorry. It was behind another window with all the people in here. Who's doing it? I will do this. Okay. So, okay. Hello everyone, my name is Thomas. Oma will help me presenting the current progress of the Operator Working Group. Now to recap a short recap on the chart of the Operator Working Group. So, at first the goals of the Operator Working Group was to define an Operator Majority Model to define some patterns and use cases for end users and so on, how to use an Operator and kinds of Operator Security. Some points defined what people may want to get out. So, this would be what are the components of an Operator, what components are not part of an Operator, and best practices and patterns. And the first defined goal of the Operator Working Group was to finish the definition of an Operator, and therefore we created a white paper. So I think Oma will take on this slide. So, what have you learned so far? Oh, sorry. Can you hear me? Yes. Okay, so sometimes, okay. So sometimes it's about semantic, the wording is something that is very important. And that is one of our main goals to get the wording and the semantics right so everyone can agree on it. That being said, we are trying to make the definition board range, trying to describe the curriculum, the characters of an Operator and not being very specific. As we understand that an Operator is something that is broadly used already. And when we start talking with people, we got some interesting topic and comments. One of the examples is the threat model that we will take with security. And the second one is an Operator outside of Kubernetes as we are CNCF working group. That is also something we are trying to think about it. And what happened in the last few weeks? So we started the Operator White Paper. And Thomas said lead a small group of people. One of them. And we tried to get consensus inside a small group. And from that consensus to go further out. We talked about what an Operator is, and we tried to define some base wording and semantic around it. Which leads to the capability model. That is described in the document. We felt that it's more appropriate for the documentation to be structured in a capabilities way. And as I said, we found some outside contributors, some from security and some from other working groups around Operators. We're starting and there is a draft and there was a link in the first or a second slide. And going forward, we will probably try to build something tangible as some code samples and maybe solve real world questions around operators and how it can help in the operation of day one and day two. Okay, yes, so currently we want to get to the first draft of the paper. So we are currently adding an improving content in the working document. We try to agree on the sections during the meetings. Yes, and if we think the sections are ready, we mark them for review. As some of you might have seen, we have sent out a request for review in the mailing list. So everything which is marked for review can be reviewed by everyone of you. So comments are very welcome. After two weeks of this review phase, we will raise a PR against the IP delivery repository. And afterwards we'll discuss the changes the last time it merged. Our goal is to get the first final draft until the end of 2020. So I hope that this will work. Yes, currently, we are trying to make good progress. So I want to relaunch the directly meetings which are mentioned in the CF calendar. But when there is the necessary when it's necessary to have additional meetings, I will also invite for those meetings to get to make faster progress. And we would like to set up and operate the white papers like group is for the security white paper. We will discuss this in the next weeks and we'll give you an information when the second. But we also might want to think about operators outside of the community as well. And that's what almost said before. There could be operators without communities and I think as a since the project we should be aware of this. Just as an example, like, like safe engine also Terraform could follow the operator pattern. But we will discuss this. In the last talk with you and we also, we also thinking on doing a survey about operators. So we want to know which problems and use and practitioners are facing so we could answer probably answer them. And also, I think it's interesting for the, for the target audience, which frameworks are used. So last but not least we want to make progress and we want to get the use, use for document for any users and practitioners. So, so how to contribute. And there's the link for the doc you can open you can read you can comment with value comments for any kinds. If you want to add something, of course, you can add it. If you want, if you think the wording that is currently in the docs is something that is not clear, please, or comment or comment or submit a fix. And if you're not feeling confident enough to contribute. If you don't feel like that and contribute. You're also welcome to join our bi weekly meetings, or send the feedback straight to Thomas or for me. And the feedback is very important for us, as we try to get consensus around this topic before we go back and present the final draft. But not least, everyone is not who is not very confident. Writing operators or knowing what an operator is. Everyone of those people is the target audience. So, exactly this feedback is very valuable for us. So, this was the state from our working group. I hope you enjoyed it and was short enough. And yes, if you have questions, please feel free to ask. Thank you. I think we discussed this before so this has been a long time in the making or better. Thank you for making so it's good that they've been making now actually progress on this great that you're involving the other operator project and also it's a security I think that's that's really good that we have widened the audience there and I should have the project or I really covered in there also the clear focus on target audience, I think is helpful. And again, yeah, I think it's also good that people contribute to think but we just should avoid to say that okay let's start all over again because that isn't really helpful so I think this is moving in the right direction if you have, especially if you have the project, somebody from the project in there from the individuals, we can sort of also the projects working on operation related work will feel well represented by the white paper and also that you talk to the security folks how they built their white paper and cope it. It's great that also that we have offline collaboration obviously same as Thomas being from Europe we highly value offline collaboration rather than 2am in the morning. Europe type of collaboration I also know that some people can try to meet things as well, opposite you to other commitments so that's important as well but good to see this moving forward. It would be great if you could have the draft that you said by the end of the year before the holiday seasons maybe ready for next meeting would be one more before holiday season that would be amazing because then people can connect before. So usually after new holiday season things get get get dragged along and especially this year everybody will deserve to have some relaxation time but that's good. Good to see that progress and yeah thanks also for stepping up here. Thanks for. The next one is flux who wants to be for a flux senior. So we have a presentation is it appropriate to run through that. It'll take about 10 minutes I think. Yeah, that's fine. Then the recordings will also be shared afterwards even for people cannot join it though. Cool. All right, so I'll try the share screen. Someone give me a thumbs up. That's what they expect to see okay great. So, flux has entered a proposal to move from sandbox to incubation and CNCF. We've been referred to SIG app delivery which seems appropriate and so this presentation is really about making a gentle case. For you all to endorse this move ultimately. So I'm going to give a bit of background on flux and where it's headed. And then I'll try and press my suit for for making a move into incubation. Flux if you're not familiar with it is a fits into a continuous delivery category of software so it's the idea is that you keep all your configuration in get and flux sinks that into a Kubernetes cluster. So this means that changing your configuration and your operations can be done through get operations pull requests and so on and this became known as GitOps for a while flux and GitOps were sort of synonymous but then GitOps sort of took on a life of its own and since then there've been other projects which have been called GitOps and flux is in currently in the CNCS sandbox. We bit of history so flux was about three years in and up to version 1.13 when it entered the sandbox which was a bit over a year ago. And once the end of last year around the same time we're entering the sandbox. We were talking to the Argo team, I see Alex is here. Since I go is also a very strongly GitOps oriented project, well I go CD is. And we thought maybe we could merge efforts. I would say that didn't work out. So in the start of this year. We did some experimental work to in the direction of what became known as flux V2, which I'll say a bit more about in a second. And as we're nearing the end of this year we are getting towards the point where flux V2 has got feature parity with flux V1 IE. It can do all the same things, although not necessarily in the same way because otherwise what would be the point. So by way of comparison flux V1. It syncs a Git repository into the local cluster, and it does some automation with regard to updating YAMLs in Git IE making commits on your behalf when things happen. Flux V2 is built from scratch. And uses things like the custom resources so that it is more sort of integrated with Kubernetes specifically. In doing so it syncs arbitrary numbers of Git repositories to local or remote clusters, and it does the automation thing as well. So it's a lot more flexible and part of the flexibility comes from being based on what we call GitOps toolkit which is just a sense of control is that you can mix and match. Whereas you can add your own things in there if you want to do things that are not covered by flux. And you can hook it into other systems like Igo workflow and Tecton. If you want to accomplish things that are sort of outside the scope of that you can do with just writing code. So this is this illustrates that transition flux V1 work. This is 2020 so flux V1 work is green and dark purple. So to start that was pretty much all that was happening and then GitOps toolkit and flux V2 is yellow and all the other colors more or less. And you can see there's sort of transition from mostly working on flux V1 to working more on flux V2 without giving up V1 entirely. All right, so that's kind of where flux came from and where it's heading. So let's look at incubation. So these are the criteria as set out by the TOC. And I've just picked out and bold the things that are relevant here so the project must be you successfully in production by at least three independent end users have a healthy number of committees and substantial ongoing flow of commits and contributions and clear versioning and I think that last one is a stand in for having sort of process around releases and some idea of there being you know backward compatibility and so on. So, since we've been in sandbox where a lot of things have happened has been quite growth phase for flux. And the headline with respect to production users is that flux was alongside helmet the adopt sector of the CNCF technology radar for continuous delivery so in CNCS own words that means that it was widely adopted and fewer or none of the respondents recommended against using it. The respondents in this case are the end user community of the CNCS so that's quite an endorsement I think. The people that fronted up and put themselves in, you know, read me as production users tripled more or less or just about tripled. We've worked at a bunch of case studies with various companies and some of the people from those companies like Steve Wade from metal have sort of become unofficial ambassadors for flux and get ups as well, which is great to see. And all the other sorts of indicators have gone up by similar factors in the community or with respect to the developers. Historically I've had mainly we've works people, the maintainers because it was originally a we've works project. But now half the core maintainers are from outside we've works, which is fantastic. In part, that's because we have, well, in the same vein with formalized governance to make it, well first of all to have written down but also to make it much more focused on consensus and trying to encourage contributions. And we have weekly meetings that alternate between sort of Europe friendly time zone and America's friendly time zones. And we were relaunched websites and added a blog and we have a team of people that are specifically trying to manage community and sort of social media and so on those channels. Other stuff that's happening very quickly. So we have a window where once we reach feature parity with flux me to want to support flux me one users for six months, at least so that they can migrate to flux me to so that's they already have a chance to do that. But we want to have an official set of windows that there is a good period of time for people to be able to do that. There's also a proposal to move flagger, which is another continuous delivery project into flux project, which is nice to see. And there's been some events which are specifically about get ups, get up stays which was run by we've works. There's been a US version of that and Europe version of that. And that was quite successful and fun. And there's a get ups working group which I think that's actually on the agenda for later, or at least something approaching it is. So going back to the incubation criteria. Fluxes use successfully in production. We've got about 77 about 77 about 80 people that in a read me that have volunteered themselves as production users to pick out a few control plane IBM and recruiting. But also remember the technology radar where flux was in the adopt category which I think I will repeat in fact I think that's quite an endorsement from the end user community of the CNCF. We have a healthy number of committees. We have the committers from outside we've works, although it was a historically we've works project. And there's about 13, I think 13 at last count, people who are a maintainer of one or more of the sub project. There's a substantial ongoing flow of commits this is subjective and it's called out to such in the criteria but there's on the order of 10s of PRs, the week that get entered posted and merged. Often from first time contribute contributors and non maintainers and clear versioning scheme yeah well. We were at 1.13 when we entered the sandbox now we're approaching 2.0 and we use Senva so we're quite concerned with backward compatibility and so on. So, actually firstly, thank you very much for making room for us in the agenda. And now I'll go back to questions. So, when do you think that that it will be a flux to already released or is it pre release still. Maybe beta level so it's not at a 1.0 or I guess it would be 2.0 still sort of going through the zero point minor versions. We're pretty close to feature parity across the board with flux the one so I think in the first bit of next year, that's when we'll start thinking about. A GA general availability. It's worth noting that we actually there are users of flux be to already in production. So, even before reaching feature parity and and removing the beta label we do have people that are using this and in anger. I mean, it's just a, a general question so by what would be for the ideal time because you're switching over to the new version which is currently not released. Yeah, but really in version four, we two might be, I mean, the religions process and it happens overnight obviously anyway so that's why I was asking. There might be time on the end user examples that you brought up or the user examples. You can obviously list also other commercial software vendors in there I know that you have end users I recommend using end users, because you know, if you're talking about flux dates and users there's obviously some examples were then it's up to the two seats to decide whether they accept somebody as end users it just makes the process easier if you're not listing other companies that those commercial software solutions on top of flux as as the ones for the due diligence. Cloud and maybe falls in that category. Yeah, I've been before in the category. You have those. I'm just making the point that it might be that that is easier for that process usually. Yeah, and obviously if you have some on version two. That's obviously helpful. I think I mentioned before. So having them on retool is definitely helpful, because that's the latest version is that it was bigger cut in there. Yeah, on that version around flag or I think it would be a separate discussion on how you think of this is how this is going to work and how this fits together there. And it's also for for us from the from the due diligence point of view we have to think of how we're going to evaluate this. This is obviously happening more than projects that kind of merging together and getting chosen to each other and we had this situation in the past. It from and from a due diligence perspective it just complicates things, sometimes a bit but not necessarily too much. I would like to learn more. I also have to admit that we also want to as part of this process also want to have a closer look at the two. But we didn't say it's not two projects or essentially then three. Do you see github's toolkit as a separate project. Not really. It really goes hand in hand with flux be to flux be to maybe more like the user interface. And with the component pieces being github's toolkit. I really just wanted to make the point that there is an effort to give room for integrations. Yeah, and what I'll definitely do again as I mentioned, I'm thinking that you see because like we just want to follow the official procedure. We don't want to slow things down but still keep the, keep the proper flow of things here. Yeah, thanks for the update I'm opening up to questions from the wider audience here. Thanks. There are no further questions this topic we have one more left that I think a lot of people are waiting for. I'm sorry, I was, I was pausing for, for other people to ask questions so as a point of kind of protocol for moving forward here. I think what we're looking for is the app delivery sig to say yes let's enter the due diligence phase. Correct. That's the next kind of point procedure. And usually that that's what the part of procedure is that you see tells app delivery have a look at this and started due diligence process and let us know when you're done. And so have we gotten that has a to cease. No, but that that's why I brought it up yesterday and but I can follow up also with our to see is on to to move this forward. And it's just a formality but I don't want to start doing things that that's within the responsibility of the to see. Or check whether there are any opinions from the to see that we have to take care of first but as we are talking about this right now and as we're getting off this call. I'm talking to Michelle who's our to see liaison to help us push this, push this forward. And I was a product yesterday and so that you see call. So the TOC will say yes please, please go ahead and do the due diligence and then the app delivery sig will do that due diligence. Yes, and they might also decide that they also want to have a due diligence by another working group for example securities is very often offers one that they want to have a look at things as well. But we'll stay in touch with you I think Michael and Cornelia you will be the primary points of context if you need anything we'll just reach out to you. Sounds great. Because usually we also take also on the case point of view. It's really some time to dive into this like even trying out solutions working with them, playing around asking questions. And moving things forward but don't expect is like, I think now it used to be and maybe a bit more painful like this process in the past but now to be standardized more of the due diligence work. I think it should go smoothly. I just want to ensure that we're not starting something off that the TOC wants to have first opinion on that's the only thing. Okay, next topic is, I think it was brought up by my mispronouncing. Yeah, sorry my mispronounce your names. No worries go ahead and try. Go big boss. Yeah, just just make it easy for you should be okay. So that's the whole topic around the employee might also have at some corner. Obviously there was the, it's about the github's working group that you announced during cube cube con in that conversation also with with Alexis and others. So I started that first chart the document I think it still needs some more content there there were also some comments already on there so like more semantics but still important about this. This topic around like calling it a manifest or calling it something else. Just, there is a lot of interest in this. I think you also submitted the github's working group as a sandbox proposal as well. But I'll give you a chance to just introduce it to the app delivery as a whole. And then obviously ask others who have already questions to ask those questions. Yeah, I mean just just to be clear I didn't propose it but I just wanted to bring up the discussion so if Michael and others would want to chip in with details that'll be awesome. So I think I'm sure big. I'm from red hat, but then I'm basically talking as part of the Argo community I'm an Argo contributor, and I have some of my friends in the community in this meeting as well. And I think I wanted to bring up this topic today to kind of mentioned that fear very excited that there is a work group that has been proposed and I would love to know more about it. And what I've read online. It's a great move I think this does give us a chance to actually serve different customers and cube and cube users around the world around github's practices. My only comment on that would be that it would be great if we could make it a little more who vendor neutral and a little more technology neutral if possible. Which means there are other CNCF projects also that like our CD, which is pretty popular out there which is to ensure that we drive this from more from a practices perspective than a very specific technology perspective. So I just want to bring the topic up I let other folks chip in if needed Alex Mukulika John in the other community if somebody wants to add something. Sure, I think you've covered it pretty well. Yeah. And so I would love to jump in right away and I will say 100% that we are completely with you on the neutrality. Our goal here is not to make this a technology specification, or anything like that, very specific, you know, like that it's, we just talked about flux that it's flux and nothing else. This is really about addressing the set of concepts, get ops is a set of concepts. And it is really about serving the end user community. As I like to joke around that get ops is the center square on the buzzword bingo card right now. Everybody is talking about get ops and everybody is claiming get ops support or get ops capabilities. And we don't believe that, you know, taking legacy approaches and calling them get ops is going to serve the end user and the consumer very well. And so this is all about serving the end consumer and helping the community understand that when it comes to doing modern cloud native operations, we want to embrace certain patterns, like, fully embrace the reconciliation loop that is so central to the Kubernetes. Now this isn't specific to Kubernetes back to the point of technology neutral and vendor neutral. Even though Michael earlier talked about the fact that flux v2 is from an implementation perspective more Kubernetes, but what we want to do with the get ops working group is really talk about the concepts. We want to talk about the fact that it's not just the runtime reconciliation loops but that having a reconciliation loop around delivery that enables us to do things like drift detection and things like that. Those are the concepts that we're aiming for. So I completely, you know, being one of the organizations and for those of you don't know me see Cornelia Davis CT out we've worked being one of the organizations that kind of brought this to the working the app delivery say again and came out with this this concept. We, all of us are myself, you know, we works as well as the other organizations are really looking at this being a conceptual thing and serving the end user community. It's not a vendor. It's not a ISP play. Sure. Thank you. 100%. I will say, so I'm sorry, I promise I'll zip up in just a moment. When when Eloise sent out the note and said here's the Google Doc, you know, register your interest. I was just so overwhelmed and delighted with the number of folks and to hear you say it with the emphasis that you did that you're so excited about this. We thought that would be there and I think it was made even more than we anticipated so thrilled with the interest. Thank you. Thanks, Cornelia. So going forward, will this be a work group under absolute delivery. App delivery. That's the expectation. Okay. That's my expectation. Yeah, we're pretty flexible on the work group. I think we just chart the document still needs some work and we need to do some housekeeping that was also brought up yesterday in the TVC call. Because you wanted to announce it during KubeCon we were okay let's keep it under currently deflux city org. I brought this up to the TV for him. They are okay that it takes some time to move it out of the web. I think this this would just make it definitely more neutral. So if you've already talked to to the CNCS if you need any help there. Please let us know. I mean technically you can create a separate org and just invites the CNCS does the most projects do that they have full control over them so that would be easy. Easy to do. I think it's also crucial if you think about the governance model, especially as it comes from flux and we want to have it open but there's like other projects are interested in this. And make also like working on the on the tractor topics and moving the things forward. This is Paul Mori from Red Hat. I know a couple of you already. I wanted to just suggest that since there's an intention to make it vendor neutral. I can take a little while to get like GitHub repos moved around and stuff like that. I think it would just be worth putting something maybe a couple lines in the read me Cornelia to articulate what you just said around neutrality. I took a look at the repo the other day and and sort of had some questions about that so I think that would go a long way. Thank you. Okay. Thank you for that feedback will do. I think it can be done done done easily and I'm happy to support on this. If needed, he created a separate org have to check in with the Lexus where this is but I know from like meeting project from the CNC efforts usually goes easy or sometimes a bit different. But that I think would definitely be helpful and also with the collaboration on the on the charter. I think I'd recommend maybe some of the charter orders that will come. Can comment on it as well. As you read it obviously has a message interest here so Hey this Josh Berkens from SIG contributor strategy. The working groups can either be independent of SIGs within the CNCF, or they can be under SIGs. It would make sense given the nature of this one for it to be under app delivery there isn't a clear reason why it would need to be sort of shared between multiple SIGs unless I'm missing something. In which case it's actually fairly easy to SIG app delivery have its own repo at this point. Yes, we do. It would be to just give the get ups working group part of that repo. Or if there's some reason for it to have a separate repo, then just email the CNCF staff and ask for that and explain who's going to administer the repo. Yeah, so I'd love to, I like the way that you characterize that and I do want to pose a question I'd love, especially since we have so many active participants today to get some other thoughts on this. The get ups is something that we often talk about it from the perspective of applying the get ups model to app delivery. But the get ups model is actually far more generalizable than that. It's not necessarily just for app delivery. It could be for literally anything. So I'll give you an example. We run weed cloud at Weedworks. We run weed cloud on AWS. And one of the things that we're putting in place, one of the things that Amazon recommends if you're running on Amazon and we do run on Amazon is that you have a learning setup for your S3 buckets so that if the permissions are inadvertently or intentionally set to public, you have to have an alert so that somebody, it doesn't happen inadvertently. So there is an example of where a get ups pattern works really well is that you can specify, this is the way I want my permission set on S3. And it's constantly watching that. And you've specified that in a get repository somewhere and you've got some reconciler that is watching those permissions. So here's a case where it isn't so much about the app delivery but it's around configuration, operational configuration of some other system. And so I haven't been super worried about whether we do this under app delivery because I think it's a reasonable home and it gives us kind of a starting point. But get ups itself is not constrained to just application delivery. So thoughts. Everybody is using get ups for clusters reconciliation. They have started using get ups for lambdas. They've started using get ups for AWS resources. I also agree. I think since so many vendors and companies are interested, it felt like app delivery sake is more neutral home. And, but any other suggestion is fine. Yeah, yeah, 100% agree. I'm not I don't object to it but I just wanted to bring it up in this, because it's so so much broader than that. I share that feelings from the operator working group. So it's kind of the same we started with the conversation around Kubernetes and then understand that it might be broader outside and for and be applied. I think that is not a necessary Kubernetes or not necessarily operating things are inside Kubernetes. And I think that's something that we will in SIG up delivery will feel more and more that things are starting from the application perspective, but going broader and also infrastructure and configuration. So I think that today's what I think that what since you can offer is obviously this in independent and as multiple vendors are interested. Working groups have kind of an interesting history Josh correct me if I'm wrong but if you look at some of the CF documents. They are still stated as like being sponsored by TSE member then moved into the six. There's a lot of documentation out there how they actually work so seek at delivery is is open to is obviously open to supporting this as well as a way to try the documents with a lot of people there we can help you. Setting up meetings and so forth you can also help you with organizational issues like if you need a dedicated repo. You can move out of the flux repo because it just creates a lot of questions, or like an imbalance that some people don't feel comfortable with, which I think is fair. And then we should ensure that we have to put in the table has to participation of this. There I think the key is a charter document and also these exist currently in multiple places I think some cleanup work needs to be done. And I think what's kind of confusing is a submission as a project and as a working group at the same time, which is some others like if you look at serverless they have a repo they are kind of a specification project. So kind of like a working group. I think the key question is do you see this as something that will go through that process of a typical CNCS project where it's like right now it's sandbox. Then we move it to incubation and then we move it to graduation, or is it really the collaboration around the concept and delivering things that's much closer to work that a working group usually will do. I'd say let me point out that serverless isn't a project. The thing that's specifically a project is the serverless workflow specification. Which is different from the serverless working group. In other words, the serverless working group that has a project about one aspect of serverless technology where they want to specification. And I could see this get ops working group eventually having that right. You could have like the get ops working group and then at some point they could decide that they really need get reconciliation loop specification, which would then be a project. I mean, certainly some of the goals that that I personally and I think some several of us have in mind is that we want to within that the working group we want to do things like document a lot of use cases so that we can help our user community understand where this is applicable. We want to maybe establish a set of patterns. And all of those things I think are more around the helping users get started than they are a specification, whether there's eventually a specification. I think it's too early to tell I can't think off the top of my head of something that is so strict that I would call it a specification. I want to talk about the term manifesto and there are some, you know, very valid concerns with using that term from from kind of a diversity and inclusion perspective. But I like the concept of you know the agile manifesto did quite a bit to help the community understand that taking your waterfall process and breaking it down into two week increments against your waterfall process wasn't the same as real agile. It's really more along those lines of helping people kind of shift their understanding to the, these new models. And so I don't know if there's going to be a specification at the moment I don't see anything off the top of my head. Yeah, maybe that's, and we have some discussion points around the working group. Try to get some more clarification in the next weeks because we're already on top of the hour here. And then adjourn in two weeks from now where we have hopefully more more clarification. Okay, those topics. The good thing is, we have the charter document where a lot of people to clear interest, and I think it would be good to find a way to keep these people in the loop. You have like credit quite a lot of interest, which is good. And I think getting them on the first call is definitely helpful if we need a meeting. That's usually something that CSF can help as well like scheduling a meeting. The CSF clinic gets fuller and fuller though. I think it's definitely doable. If we need one there. Right, I think as a next step we need to figure out how to have this group engage etc etc. So, yeah. We'll definitely want some kind of a regular cadence in terms of working group meetings and then we have a lot of work to do to set up the scaffolding. I think is the next step. Okay, yeah, that's sweet. Let's continue this discussion two weeks from now. It's good that you pushed forward and moved things and I think it's normal then when you start things off fresh and you want to move fast. You have to do some of the cleaner work later on which is what we find. Yep, just to be sure that everybody feels comfortable with the direction we're moving in. The good thing is there is excitement. And let's work on this and put it on the agenda for next time as well. Let's put that and move by then. Sure. Thank you. All right, I think that we are done for today we are usually with scale for 45 minutes but most of the time we saw the entire hour was good to see everyone again after cube calm. And Thanksgiving. Let's talk again in two weeks. And that's a nice day by. So, I always I have a very off topic question for you. Is that a real background behind you, or is that is a real background behind me. Yes. That is such a tremendous piece of artwork. That's not fake. That's what I, that's not safe that's actually other work yet. Yeah, no that is gorgeous I've been looking at that art the whole hour and it's beautiful so I don't know why you've been hiding that with your your backgrounds because it's no it was just the other way around but was sitting the other way around I changed my this is actually a photo that I took so this is not just bought artwork this is a photo that I took in Thailand. That's fabulous. That is fabulous. So I might start selling my photographs. There you go. Yeah, new, new, new source of income. Yep. Business, I think. Yeah, yes, it is a lot of competition. Thank you everyone. Thanks. Thank you.