User talk:Bryan Hilderbrand/Meeting Notes (27JAN)

Raw transcript:

Yaron: Here,

Lex: here

Bryan: right

Yaron: Oh, there is.

Markus: ah, someone Ingram

Yaron: You just talk of you just mentioned his name and he shows up.

Lex: There you go. Hi Brian.

Bryan: you guys Morning.

Markus: Good morning, Brian.

Yaron: Oh, yeah, good morning, right? Oh.

Markus: Oh, Richie. Hey, we have

Yaron: All right good.

Lex: Hi Richard.

Markus: a Hello World of overpopulation here.

Richard: I

Yaron: Right. Yeah.

Richard: our performance. I'm just a visitor. I'm just listening. I have to prepare my conference contribution for tomorrow, but don't want to miss you here.

Yaron: Yeah, well. What conference is it?

Richard: It's a university Summit. It's an open source conference in. in Germany and yeah, it's it's it's an I think the most important open source Enterprise open source event in Germany and We are Partners there.

Yaron: Yeah.

Richard: And so

Markus: Richie.

Yaron: Cool. Oh wait that we last we lost Richard. Okay, I would um

Gokhan: You.

Markus: But I can turn. Yeah, there is

Yaron: Okay, Richard your back.

Richard: Yeah. Yeah, back. Okay.

Lex: To Richard. No, that's the other Richard who is back.

Yaron: And now and now we have the odds of the Richard and yeah and James the

Richard: Yeah.

Yaron: two different NASA guy.

Lex: All right, well there I have.

Richard: All rich as online now.

Lex: Multi.

Richard: All important widgets

Yaron: Oh, yes. We have two and two of which here?

Richard: so you need an image from now, you

Yaron: Yeah.

Richard: know? Okay, sir camera. See

Yaron: All right.

Lex: Is that a beer?

Markus: Are you drinking beer in the office?

Richard: Yeah, because the coffee was out.

Markus: Richie.

Richard: Now, I went to the kitchen and and there was no coffee anymore but there was a healing ahead. That's okay.

Markus: Yeah. One more.

Lex: Hi Cindy.

Richard: Well,

Yaron: Yeah.

Rich: So that means we're gonna make progress.

Cindy: Well, let's join you about pickles

Yaron: that

Cindy: this week. It's fear. No.

Lex: Wait, maybe.

Cindy: Sure.

Yaron: and so okay. Oh, wow. This is this is the most people we've ever had I think which is great. 10 or so people. Yeah, but just a few things briefly and Brian I think is recording this it's not going to go anywhere, but the the transcript will go online probably so just you know, just be aware of that. Don't don't say anything that you don't want people to read a mangled version of some point in the future

Markus: Okay.

Yaron: um and oh it well. Yeah, and I guess everyone say I did and James I'm glad you're here too. We have now representatives from the three or four depending on how you look at it main contenders assuming the the Wikimedia foundations one is still in any sense a contender for this project. So most of you know each other I don't know and I don't think we should bother doing introductions but it's it's great that everyone's here. I'm not sure where to start Lex has done the most work, of course and and everyone should check out his contribution to the To the Canasta slash infrastructure pages of what I forgot what exactly what it's called. He's even he's even actually created a solution on a separate GitHub project called. I guess you just call it media Wiki Canasta. I'm not sure just to remind everyone again can ask is just the name of the project but it's fine that the people are using it also as a as a shorthand for the actual name of the solution

Rich: Your own can you make a one or two sentence summary of what can ask it is?

Yaron: Sure. Yeah, the the goal behind project Canasta is to enable products based around media Wiki that can be downloaded for specific purposes business process management or any of a number of other things. So that's divided into two parts. The first is making it easy to create and in turn download such a product. And the second is actually creating the products with the data structures and all that and we're focusing on the first part right now as we as we did in the previous meeting or two. Yeah. And and this will be useful for for things besides specific products. Just just for downloading media weekend. It ties into a previous project that I guess never really came up went off the ground called the sunflower distribution. but this could be useful for a lot of packages that people want to create of media wiki+ extensions. Yeah, Rich.

Rich: Thank you. Thank you for that summary. Could you also State the immediate questions before the the group today? And what are the you know, there's there's like long-term goals, and

Yaron: Yeah, right.

Rich: then there's what we're trying to accomplish today.

Yaron: Sure. Yeah, that's what I was going to get to. I mean we have here people from three or four depending on how you count. It solutions that already exist in One sensor another for docker-based installation. Actually, maybe even five now that I think about it. I mean that you know, people are really coalescing around the use of Docker for downloading media Wiki and installing media Wiki. So the question is what makes the most sense for this specific purpose. um, so yeah, I mean we've heard already quite a bit from Lex, although of course, I want to hear more and we've heard from Cindy about the Wikimedia Foundation one, and we've heard a little bit from the From the blue spice people. It's I guess I I mean, I think it makes the most sense to start with James because Mezza even though it seemed like the obvious FrontRunner at the beginning at least to me because it's the one I had heard of it hasn't really been discussed so far. So so if you don't mind James, this is a lot to throw at you all at once, but I curious what your thoughts are about this whole thing how much you've read and and what what you think whether you think Mezza and I guess you could include quality box in there, which is a fork of Mesa created by Greg who's not here. I know could how much do you think they would be useful for this purpose?

James: Cameras, so I'm not gonna be able to talk much because I'm next. multitasking at the moment, but I

Yaron: Yeah, okay.

James: think Rich can probably speak to what moza is if that's what you're wondering and I can listen and and provide feedback on that. I've read a little bit of what you're trying to do, but not a whole lot. So I totally take some background.

Yaron: Oh, you really are multitasking.

James: Yeah, there are people outside the space station right now.

Yaron: Oh that no.

James: well

Yaron: I heard a baby or something. I thought that was from you. Okay here.

James: Oh, there's a you know, some triple There's a there's a kid trying to multitasking.

Yaron: Yeah, okay.

James: pull down my computer and

Yaron: I'm happy being in third place for

James: and then

Yaron: that and that's that a priority.

James: yeah. So yeah.

Yaron: It well very briefly. Could you could you say saying one or two sentence about the current if the current development status of Meza, is it is there still? Do you I mean, is there still development being done on it from your perspective?

James: Yes, so we're we're using it for our production servers. At JSC actually, I think there's a few different orgs doing it. and we're on media Wiki one of three one. I have a one up three five Branch out there, but I haven't completed it yet one of the major things there and one of the holdups from not moving further has been that they're a bunch of extensions that are bundled with it right now and I'm debundling those because there's a bunch of them that like haven't caught up with my own maintained extensions included, um that you know, you got these things bundled and they're not ready for one or three five. You can't really do anything about that. So anyway, Yeah, when I get some time, that'll

Yaron: Yeah.

James: be released. And then that'll make the maintenance process a lot easier

Yaron: Yeah. Okay, cool. Well, yeah. Okay. Yeah, we don't want to leave any crashes in space do okay. I mean I guess then if you know given given all the the good Lord, what am I talking about? Given all the projects that are repping representing here. Maybe it's new. There's a good time to move on to to hollow health and blue spice. If any of you want to talk about I mean, obviously there is a Dockers Solution that's part of blue spice. It would be great. If any of you talked about whether you think it makes sense for for that software to be used for this purpose. How well do you think it would couldn't work? um, and you know how it how it Compares especially to to Lex's solution, which I'm just going to call Lexus solution because there's no there's there's no short name for it the data spec system builder. Yeah.

Markus: Um, yes. So I guess the main approach behind the blue Supply stock are containers. We build blue spice, as a Media Kit distribution based on composer. So we have this composite files where we actually enter the extensions. We want to have in there and then we just well Google smile. But we just drawn a composer, install command and it draws all the extensions. Um which we need. So the question is how we do, how do we do that? Well with various flavors in basically we have a set of composer files, I mean you know the media week you can run half several composer files or split up one composer file into several ones. So there is one for the base installation and then there is one for say our PDF feature and there is one for the for the paper and we just add them on top of the. So there's a folder and there are several composer files in there which Define these sub aspects of the software. So if I transfer this to a project canasta, We could basically agree on one composer file with loads. The basic set of extensions. We want to have in there. And then everyone who wants to build on top of that. Just adds another composer file adding those extensions they want now. It's it's a little bit more complicated obviously. And I think that is the point where we're coming can jump in because sometimes we don't have composer files for extension. So that is in the blue spice environment. We set up everything. So each of our extension defines, a computer uses a composer that Json file defines the dependencies. But there are ways to mark this somehow, And of course, the it all depends on having these composer, libraries registered somewhere. I don't know Google, if you want to quickly talk about the the composer registry, we have

Lex: No.

Markus: I yeah, you

Gokhan: I'm trying to unmute myself. Okay. So actually composer side is more strictly handled by our development team. So I'm not immune so much And my main point is just getting toker containers and images as fast as possible and as quick as possible. So, One mainly to using four days is John CI. So, my builds are based on GitHub stories, and I have some Toker files, which is multi-stage because the software itself, so demanding. So I have to keep the images as small as possible. so, I'm not to Stage provides that to me, and If I need some sort of non-standard Docker image, so I'm doing it on git. So Deploying some. Extra extensions or as a sub module on the gate and then container just build itself with continuous integration system. So I'm getting out the image. I'm using that this way.

Yaron: Yeah.

Markus: so, maybe to make this a little bit more graspable from Where as good cons that I can mostly. I'll give you the developers view here, but it just to see for you guys, how we do it in how we integrate media key. You can see this is our GitHub repository however, media key. And we basically sync this with the media VQ repository, but we add a folder called Blue Spice in this case obviously and as a build folder in here and now you can see these composer files. So that's boost by free. That's the end up. That's media weekly extensions and in these composer. What? In this folders? In these composer files. Now you have the extensions, we just add to that. So, that is one. That is the one that defines blue spice 3. If I go back because that's more familiar to you, the media Wiki distribution composer. Json is the one that defines the base media Wikipedia package. So in a similar manner, what we do is for the pro version, we basically build on top of this repository and at additional folders in here which is then April's best pro folder or a cloud instance for what. And that could be a data specs folder or a metaphor or whatever. As long as we can handle, extensions, using composer. We just drop. You know, that definition file in there, run the build command, and then we have a working blue spice. um, last thing I have to say is, of course, that is the big process regarding media weekly. So the docker container, the environment we use is fixed for all flavors. We use. So if we, we have the same environment for the docker and same dock environment, for our free, as we have for our Pro solution, or almost identical. And that is one thing where we might have to talk about which might have to talk about. So if we actually have to use, like, if you guys want to add to the docker file because I don't know, you prefer this thing search over the elasticsearch, for example, then that's on a different table. I mean, we do have these Docker, definition files publicly available of course. But the question is, how could we deal with those? Right? So I think I see two questions here for us. When using the goosebuster approach that is, how can we make the docker image itself, flexible? So the infrastructure or do we need that or do we agree on one infrastructure and the second is How do we maintain a way of making composer? Know, all the media weekly extensions, and for composer, you have to register it with the packages. That's a software. So in, in our case, we run our own packages. So we register the media weekly extensions with that packages. And then we can simply Define it as you've seen it. So, that's not a big deal registering and exemptions packages. It's, it's a one bin and a config file, but of course, we have to maintain that packages. So that's, that's the two things I think we need to consider.

Yaron: Yeah, just to be clear just for a briefly. Then the idea that the important thing here is to be able is to have a script or whatever. It is code that can let you create images. It's not about the specific images being created and you know, potentially everyone can have their own set of images using that whatever

Markus: All right.

Yaron: software we think yeah.

Markus: So basically going back to that composer approach. So this platform independent right? You could I mean my deaf environment is that, it's not a Docker. I have it on my on my bare metal machine, but I still use composer to get, like, the whole Suite of blue spies with its 120 extensions in one, go,

Yaron: Yeah.

Cindy: Can I ask a question?

Markus: Sure.

Cindy: And this sort of goes along with some of the stuff that I was discussing at the last meeting about the fact that there's multiple aspects to this and containerization is one of them and as you're saying before containerization, you've got your, you know building up your media Wiki with your composer. That's one step, but then after I'm curious, how you Deploy your blue spice Pro. How do you provide it? Either do customers install it themselves or or let me backtrack how you the docker containers that you build? Do you provide those containers to folks and then they deploy them in their own environment as they see fit. Do you have a process? I'm sort of getting at the need potentially for some sort of orchestration past. The the containerization to allow the docker container to be deployed in multiple different types of environments. and

Markus: It's good. You want to say something about?

Gokhan: Yes, can you hear me guys? Clearly

Markus: We can almost not hear you.

Gokhan: Okay.

Markus: And it's still not.

Gokhan: Microphone.

Yaron: You should probably go back to the earlier microphone setup you had.

Gokhan: Okay.

Yaron: It wasn't it was just a little quieter than it.

Gokhan: All right. So, hello. Hello, test one, two.

Yaron: Oh.

Gokhan: Eight. Sorry about that.

Markus: No.

Gokhan: Back to old one.

Markus: Yeah, that's it.

Gokhan: Right Perfect. All right.

Markus: Yes.

Gokhan: All right. So yes of course this kind of deployment requires some sort of CI. Involving it. I mean, of course you have to separate some sort of different packages or deliveries let's say or different tags. And yes, we have our own private registry for it. We are using Harbor and Cloud. Native Foundation project. So we are deploying our images on our Harbor. And then we are creating our images based it on our customer repositories. And then we are using that customer repositories as an image name and also that Branch name as a tag. and for the versioning and we are deploying to our customers, that images that are Private Registries with the provided by us, the login and password or tokens. So Yeah, this kind of deployments require some sort of automatic deployment or automatic generation but for free image we're using directly Docker Hub. So open for everyone, everyone can pull the images but the building process is the same as the pro. So it's just automatically building and pushing to the docker.

Cindy: Thank you.

Gokhan: I come.

Yaron: and Yeah, Lex. Do you have any thoughts on that? I'm just trying to get a sense for the differences between these Solutions whether it's whether it's the their use of composer. I don't know if I don't know if your solution uses composer also to that same extent or any other part of it.

Lex: now look, The media Wiki Canasta, I created is after the creation process so I want to keep myself out of that discussion for the moment.

Yaron: Oh, that's interesting.

Lex: so, what you see here is is assuming

Yaron: Okay.

Lex: that there's an archive containing all the files from media we can including a database dump, so whatever. Because that's why Meza is not an alternative to Media. We can ask that or no, it's the other way around media Wiki Canasta, as I created it on my repository. Now is not an alternative to Meza. It's post,

Yaron: Well same thing.

Lex: It's, it's a post process. Something should create a media, Wiki route directory. Put the database dump in it and package it up, and then media Wiki can ask to acts on that. So in, in order to be productive, now, I'd like to, you know, the data spec system builder is not at all, not as well. Designed and sophisticated as any of your Solutions. So I want to stay out of that discussion. My my contribution right now is, how do we handle it? You know, at the client side in order to be as simple as possible, as I think it is, that's why.

Yaron: Okay, that makes sense. I mean this really seems like two different operations here first. You have you set up your blank media leaky set of exactly how you want it to appear for everyone and then

Lex: Yeah.

Yaron: package it and so forth. But the first thing the first part of it, I mean it's it's good to have a solution for that. And of course if you have a hundred and twenty extensions, then becomes critical but It really is a separate question and for a lot of people.

Lex: Exactly. And I think that's, that's a good design decision because the build process is completely independent from from what my suggestions are about. Handling it at the client side,

Yaron: Okay.

Lex: So they are not at all connected at all.

Markus: Yeah, I would, I would totally agree. So this I mean there have been several approaches to this like creating running media key virtual machines, stock image is whatever. So, since I think what we need to understand is that these consists of several steps and we need to keep each step as independent from each other as possible and in an ideal We have like so, of course, based on my experience, everything's ideal. What we do we have that that creation the package. Creation process is independent. I can use the tarball and can use it on a web metal machine. I can use in a virtual machine, I can use in a Docker and I think we should definitely separate those two. I guess there's another component to it. That is probably the content, which we haven't touched yet. So we're talking about code base, we're talking about infrastructure and we probably need to talk about content, that's what you touched Lex when you said, database Dom. So I'm not sure if database dump is the right way to do it. But I think we need to think about maintaining content separately and then included in to the package which is then deployed on an infrastructure.

Lex: Yeah, no.

Markus: but,

Lex: I don't suggest to in you know, import or let's say production data by a DB dump. I'm talking about the initial plain

Markus: Yeah.

Lex: vanilla because what media could Master with those download links from Dropbox, provide you with is a pure media Wiki, there's no data in it at all. But of course and then you know, but that's a third thing. How do we get the Yeah, those application, you know, if you want to come up with the document management, or with the CRM, how do we get that into? But that, that's yet a completely independent, it must be independent. So yeah. The three.

Markus: Can I have one more aspect to it to the discussion? So, I've seen quite I've seen several build scripts in in the past, and Most of them ended up being no longer maintained by the person that initially created them and requiring some really special knowledge to handle it, which nobody else had. So that is part of the decision. We made to use composer Against All Odds and I'm looking at Sydney here and you know, the discussion about it. But because we said that is the technology that is independent and it's widely known. So we can build on that technology for a longer time and not saying Canasta should do this, but I just want to throw in that relying on stunna's relying on like, a bigger software for this is really for us. Now, our experience is a good path forward because that it lasts longer.

Lex: Yeah.

Yaron: Yeah.

Ad: Yeah.

Yaron: and

Ad: I have a question about

Yaron: yeah.

Ad: that and and also about Lex saying that it's important to separate things, when we think about extensions more more and more, we also, Try to think about, let's say such CRM products or document management product as an extension, of course technically its content, but it's content. That's that's part of the the application. So it's separate from user content. So should we go? Yeah. So why, why separated why not have Extensions. That. that take that take care of that, and of course, then if you, if you ship a content with an extension, then you have to run script, the you have to run a script to to to get the Stuff into the database in the wiki, but you always have to run scripts after you have done things. So shouldn't is and I'm sure that we have, of course, your own, has a solution for that and we we use page sync and there are different approaches to To have content in files as well so you can you can put it in an extension and treat that in the in a similar way.

Markus: Yeah, I like that. I mean, there's a great analysis here. So, media, weekly we have a situation. I think that's not unique, but rather a special to mediary key that is we have let's call it functional content. Like you can come up with a better word for it but it's it's let's call it functional content so that is content like the definition, the data model of semantic media, Wiki or a lure script or a common JS or Gadget or so, this is basically crossing the border between content and and programming stuff. um, and I think you. So from this perspective, I think we could, we could easily package this kind of content as an extension. I we've done it several times before, like moving gadgets into resources using resource model stuff, but still that needs to be some kind of separate thing from the base functionality. So an example, if we use semantic media Wiki, then we want to package semantic media weekly as an extension. And then we want to have maybe the CRM bundle, which provides the data set, on top of semantic, media equipment. Still, you could use semantic media key independently or with another set of data. So that's why I consider that part of the data, still a separate thing from like the base functionality. Yeah, so that's just a thought on this.

Yaron: Yeah, this is it's an interesting discussion. It's not what I want to talk about in this meeting. So yeah, I mean I had always thought of of this project as being two separate components, but really I guess it's three separate components. There's also the aspect of bundling everything together to make that initial image that you want to then release and and I guess that's also worth a discussion. I was I I think it makes I don't know if there's that even a fourth component that I'm not aware of Um, but assuming it's three, I really want to focus on the middle part. I guess you could say the part the goes between when you've created your image and when someone else has that exact thing set up on their system. How do we get it? How do we what's the what's the best software for that? I mean can anyone from hollowelt comment on that part of your system? I guess you did but it it got lost in my mind at least with all the the composer stuff.

Markus: So I think and in an easy way or the an obvious Way Forward is using Docker. I'm using a darker file like a recipe, where you just take the tarball extracted built the infrastructure extracted having said that our experience is somewhat two-sided here. So if you can guarantee me that you will run or the Canasta will run just as intended with no configuration changes, no additional like code in there. Then Docker is just fine and it's perfect, but in, in our experience, there is the thing called the it environment. Now we need to open firewalls, we need to, you know, get can say much more about this. I don't know about all these networking stuff but you know, integration in a system environment in an item and then it gets dirty because then you need to open up. Welcome machine. You need to do things you haven't foreseen before, right? And so, the question really in my view is, what do we What is our expectations? So is our expectation to provide something you can run in a production environment with multiple like, also scalable in multiple situations. Then I don't know if Docker if any kind of, you know, out of the box automation is the right way to go. The other thing is, if you want to provide it for the That can intermediary layer of expertise like people like me, right. I want to try out canasa, I downloaded I can use it and for for like, lightweight use purpose, I can also run it productive, but if it's like getting heavy weight use then I need to install it somewhere else, right? So for this purpose of having that lightweight I'm not saying testing, but lightweight production, I think Docker is a very good way to go. But last sentence, I think this, this kind of having to adopt things in heavy weight production, scenarios is something you we have to deal with in any sonar in any case. So whether it's a VM or whether it's a Docker or what, what else, any recipe will not work in context environments. Out of the box.

Yaron: Yeah, I mean, yeah getting to that my My Hope and others can disagree but my my hope is that this solution will sorry my priority is ease of installation over performance. And then the hope is once people have installed it easily and say oh, this is great for me then then hopefully there's an easy way to get it off of the virtual whatever virtual components you have if that's the word Apache or anything else into the real system and then you can do all the all the data load balancing whatever else you want to do. and yeah.

Cindy: I just wanted to say that that's consistent with what I had been saying also about having that additional level of Orchestration on top that it's perfectly fine to start with a simple lightweight, you know as Marcus was saying, you know the that easy installation and I think I have to say what you know Lex has put together is a fabulous. I think that's what you know would be great to start from Um, you know, it's great at least, you know for the conversation for having an initial deployment and it would probably be acceptable to a lot of small scale installs. So I think that's great. What I'm talking about is a future enhancement just to keep in mind for the future that again if we wanted to have this available we could have different for example kubernetes profiles for orchestration and different environments with different configs. So but I I see that as a long-term solution to keep in mind if we wanted to be able to have this easily installable in a wider range and it'll never handle the you know, opening holes, you know firewall ports outside of it, but if you can have this thing that you can then, you know make your infrastructure around it accommodate. I think we would be able to get into lot more environments

Yaron: Yeah, that makes sense to the extent. I understand it. Yeah. Well for the I mean for the for the for the the docker-based solution. I don't know. I'm hoping we can talk about the differences between these different solutions. I mean does anyone think have anything negative to say about Lex's solution or so or the thing is, you know that their solution works better for for whatever reason and that and by the way if speaking of one one minor criticism Lex, I think you should have a better name than media Wiki Canasta for your solution. It's a bit generic.

Lex: I know, I was just adapting to Your?

Yaron: I know but you know.

Lex: Your your project.

Yaron: I know but need a little too much at it.

Lex: Now, of course you can change it whatever you want.

Yaron: All right. Well, yeah, it would be good to have a name. So it says easier to talk about it. It's fine.

Bryan: I got.

Yaron: Yeah, what?

Bryan: I've got a quick just for Cindy. Is there any examples of orchestration being done right now?

Cindy: There is a project within the foundation to deploy kubernetes deploy media Wiki on kubernetes in the Wikipedia infrastructure. Yes. And that's both for production as well as in CI. And there have been discussions theoretical future. Wow. This could be a way also that we could um Deliver to third parties who want to use media Wiki, but nobody's even started thinking about how to do that, but it's a potential future.

Yaron: Cool. Yeah, so I mean for my prospective

Ad: so, I mean, for my perspective, let's

Yaron: Lexus system, let's as solution for

Ad: Yaron: that particular issue for the doctor seems to be the FrontRunner because

Ad: issue for the docker. Seems to be the FrontRunner because people

Yaron: these ones put the most thought and

Ad: Wanted the most. Thought and effort into it, but I

Yaron: effort into but I wonder

Ad: wonder.

Yaron: Oh, I'm echoing.

Ad: well, I'm not going, okay, but I want

Yaron: Okay, that's fine. But I wonder if if anyone has any thoughts any any thoughts about that, is there any reason not to just use Lexus solution any way that that other Solutions are easier to use or or better at something that kind of thing?

Ad: Well, I'm definitely not an expert in this subject, so I'm but I do know. We have a lot of experience also with kubernetes with azure But I'm not, I'm, I have no idea about what exactly the role of kubernetes is. I'm I know that if you have, if you use it that you, you can arrange. You, you can do things that you cannot do without, obviously. But I did have an interesting experience. We are what we are doing now. Nowadays or we are experimenting with that, is using Docker for everything. and, And we are, so I'm interested to hear with your experience. We just put everything in the, in the composer, in the, in the local, Composer. The local the Jason I think it is. So we and I think what we are doing is creating packages on the Fly and And get this and get the software from, from, get from GitHub or for a media weekly extensions, or from big, but big bucket for our own extensions. So and and and I said when I saw that I said, well, this I understand you just create this file with a lot of packages. And and there you can, you can put the branch as well. So you really know what you are, what you are. Which you are getting you at the button and then off you go. But this is after the initial installation of media Wiki, so we have a script to install. Well, what we typically do is we run that we go to this, you go to the server, you run the script to install and create a repository on bitdocket for that customer. So then you you create a yeah, together with the installation you create the git repository and then you do the The docker. Then you create a Docker file, which is of course. Also on. Get a you run composer. And that's what we are doing right now and experiencing. How that works. And we are going to use that in combination with. yeah, with like I said with customers that have that go to and to Azure or to AWS and that have Complex configurations, with low belts, load balancers and and the

Yaron: you

Ad: whole stuff. And I think we have a different script to to to create a containers in those situations. but really, to make this long story short, if you really want to have some details about that from our experience, I have to I have to ask. Some other guy to help us. To help me out because this is about it. From from my side.

Yaron: Okay.

Ad: So yeah. And we are definitely going to put content. So let's and of course you and that's something I that I think I understand when you say you want to separate things, you you also want to organize dependencies and so you are So yeah. And we are definitely going to put content. So let's and of course you and that's something I that I think I understand when you say you want to separate things, you you also want to organize dependencies. And so it's like Marcus said The base, the basic mini Wiki So yeah. And we are definitely going to put content. So let's and of course you and that's something I that I think I understand when you say you want to separate things, you you also want to organize dependencies. And so it's like Marcus said The base, the basic mini Wiki So yeah. And we are definitely going to put content. So let's and of course you and that's something I that I think I understand when you say you want to separate things, you you also want to organize dependencies. And so it's like Marcus said The base, the basic mini Wiki So yeah. And we are definitely going to put content. So let's and of course you and that's something I that I think I understand when you say you want to separate things, you you also want to organize dependencies. And so it's like Marcus said the base, the basic mini Wiki So yeah. And we are definitely going to put content. So let's and of course you and that's something I that I think I understand when you say you want to separate things, you you also want to organize dependencies. And so it's like Marcus said The base, the basic mini Wiki installation is, is one. If you have a lot of things, extensions that like a semantic, media, Wiki bundle. That's that's on top of that. and when you talk about products, like CRM document management, you are talking about things on top of that or perhaps you have a cargo Thing. So Docker is also our composer is, of course also about organizing dependencies. Is is, is that included in the in the ideas as well? How to is it easy to put that in composure?

Yaron: the well, at least my current vision for for actually installing data structures and so forth wouldn't be using Docker composer or anything would be Well, this separate extension called page exchange that I think is used is good for that. But that's really separate discussion. I guess you can think of that as the

Ad: Think of that as the fourth.

Yaron: fourth aspect of this is the actual mechanism to get Wiki Pages onto people's wikis. Yeah. Yeah, so there really are four.

Ad: So they're really, but you are around. You are not using your extension. As a mechanism and then put the structures, let's say the in other extensions, that's not how it's outworks. You have the packages extension.

Yaron: No, right. Yeah. Yeah, right extensions can't themselves use page exchange. They they can just they can just recommend the people. you know they can yeah, it's separate although Hopefully there'll be some kind of tie-in. Yeah.

Markus: I also would like to see this as a separate discussion, but can I ask a

Yaron: right

Markus: question about Lexus solution? Like I'm just trying to figure out the connection between your two distribution package as age script And the docker file itself. So, because it seems like when I look at the, the coast installs setup on your page, you have like httpcon if you have like installed scripts but they need to be executed somewhat in. Am I assuming correctly that you would execute these scripts or put the country files in the correct Place using the docker compose, or the docker file then, and when building the docker image that is being done? Or are you thinking about mounting things outside?

Lex: If you look at media Wiki Canasta, you're on the data spec system builder now.

Markus: And project Master infrastructure solution.

Lex: ah, you know

Markus: whole image of how things play together here.

Lex: No, you should go to the GitHub repo

Markus: Okay.

Lex: repo there. There. It's clear.

Markus: Okay, then please ignore my question and I will see if let's work here.

Lex: No, very easy. If you look at the docker composium, I just volumeed in ports.com and httpd code.com to actually Implement a, a listening Port change on Apache. Now. That's, that's of course, you know subject to optimization. It's just to, to make it viable to actually test it out.

Markus: Yeah.

Lex: So the Canasta instance settings, dot EnV file, allows me to change Apaches, listening port, By instance, which means I had once,

Markus: Right.

Lex: you know, running three, wikis in parallel, Like a pseudo Farm but of course, it's not a proper Farm because it's actually three instances with one database container and three Apache containers. But look, everything should please look up the technical details in this media. We can ask the GitHub repo.

Markus: Okay.

Lex: And then, because that's the truth is in the code, documentation, always lies until you have. Made sure. It doesn't. but I'm

Markus: Got it. Thank you.

Cindy: I just wanted to briefly answer your own question earlier about whether we're agreed that Docker is the right technology and the my short answer to that is yes, probably and the only slightly longer answer is that there are a couple of caveats to that one. If marker start over here, he would tell us to use I think it's called podman instead because it allows you

Lex: yeah.

Cindy: to run things not as root and I've started to hear more and more people he mentioned that to me about a year ago. And then more recently I hear more and more people talking about it and then the other interesting development as far as that's concerned is that kubernetes has announced that within the next year. They're going to stop supporting Docker for a containerization solution and instead.

Yaron: Wow.

Cindy: There's I believe it's built on another technology called container D. Yeah, and so they'll use that instead. I don't think that makes it incompatible with Docker. It just I think works at a different level. So there are other containerization solutions that are being discussed and if there's any way to at least sort of Stave off a little bit of vendor lock-in so that you know switching to another technology in the future would at least be up. Doable or easily more easily doable. That would be a good thing. But when you're coming to having to create a Docker compose dot yaml file you're going to be you know, really targeting a particular syntax. So it's very hard to do that in a really truly solution independent way, but just a couple things to sort of keep in the back of your mind as far as Fender locking.

Yaron: That's interesting. I mean, does anyone have any thoughts on that it?

Lex: Yes.

Yaron: It really to talk about something. I mean too early in the in the history of technology to talk about something other than Docker for this purpose.

Lex: Now I can I can contribute and then say, you know, the the infrastructure abstraction layer is not one of our business objects, our business object is contained in that archive. And in the content we put into the images folder and into the database. So like a database is a crutch. You know, if we all had two terabytes of ram, no one would use a database. We would have Json files and just query those or index them. But so what I mean is, of course, we have to completely separate the infrastructure layer from the business object layer. And, you know, if at some point, we switch to part man or something else. The only thing that should change is Docker compose yaml gets out and something else gets in and nothing else changes and we have to design the system. So that you know when you create classes, it should have one reason to change. So Docker combos yaml is like it class that has one reason to change and that is we want to move around away from Docker to something else. So I fully agree with with Cindy, I just chose Docker because it's around now, you know, maybe one day we have Quantum, quantum computers, and then we have another solution as well. But at the moment, this is what we have. So, but absolutely agree. With with Sydney, of course.

Markus: Let me add two things here. One is, if for any reason, Docker stops functioning, I'm pretty sure there are like a hundred million people out there that have Docker files and there will be good, migration parts to any like next technology. Second thing is I also agree with with Lex. We should keep it simple on the infrastructure part because I mean, as long as we don't use the specifics of Docker, I mean Docker is complex, but we can use some very specific mechanisms to Docker then migration to any other system will be Complicated by as long as we understand. This is basically a recipe of setting up a server where media we can run properly. That that's a set of And what is this? I mean, I'm being a bit blunt. Here is a set of show commands, so whether I execute those in a Docker file or an answer will script, or in a puppet, whatever essay file, that's

Lex: and,

Markus: okay. As long as we don't dig into too much in too deep into the specifics of Darker. So that might be a good design principle here. Keep it on a simple level on the infrastructure there.

Lex: yeah, and just very quickly but what

Yaron: Okay.

Lex: what, what is a little unorthodox with my solution? Is that the the Apache PHP? Apache 747 that I created, has nothing no knowledge at all of media week. It's completely agnostic. So, I volume in everything. Now, some people would say well that's too much, we should only volume in the images folder and local settings. But you see? This is now a discussion. We can have Well, it, what is more optimal, you know, should we should we protect against side? Would it make updates easier? But that's for me, that's sort of a detail to the to the larger approach. So importantly, my, my Docker file is totally agnostic of media Wiki.

Yaron: Yeah, just briefly I'm guessing no one here actually thinks we should be using podman instead of Docker, but feel free to jump in if you do okay fine. Yeah, I mean that gets to the we haven't really talked about the I don't know what the word is but but whether or not it should include Apache and MySQL in the and PHP in the image itself. I don't know. I don't know what blue spices what the blue Spice One does. I don't know what Meza does. As far as those things Rick, I guess knows at least about Meza.

Lex: A yarn. It's actually the other way around it PHP, Apache and media, MySQL are provided by the images, but media

Yaron: I know.

Lex: week is outside of it. But you are, you you now formulate

Yaron: Oh, right.

Lex: today. Should we put it in there? No, that's exactly the point Docker. Only provides the the three infrastructure processes.

Yaron: You're in yours, right?

Lex: Actually. Yeah, exactly. Yeah.

Yaron: Yeah, it's a it's just it's the amp stack.

Rich: And I'll try to make this comment

Yaron: Yeah.

Rich: real quick. So I think the idea of Mezza is that if the user shows up with a with a Centos or Debian blank vanilla machine that has it's that has access to the internet. with three lines of commands you can Have a complete system everything pre-configured and running PHP MySQL mem cache theme partstoid however much longer that that's around and it's all done through ansible playbooks. It's all extremely configurable by the user. Either prior to First deploy or after subsequent deploys you can tailor it so you can use it as a wonderful tool for an immediate system pre-configured system that you might want to blow away. You might want to just Run those three commands spin up a VM run those three commands get a complete functioning application play with it break it throw it away or you may have your production server and you use the exact same Mezza project to implement the whole thing and I think we were talking a little bit about how behind the scenes how common content is separated from user content. And so one of the things that Meza does nicely is they put all the databases and the and the upload folders for the wikis into their own separate folders and then use a common common media with the so the idea then is is that you can let some not sure if let's of saying this the right way, but you said volume in I think you can volume in the Mezza is already configured to volume in the uploads folders everything that's unique everything that is dynamic. And in day to day operations of the wiki there is changing data. All of that is in a separate data folder. That is then Broken Out by Wiki so you could volume in each separate Wiki of the entire Farm if you wanted to data bases uploads all the dynamic content and then you can keep as we

Yaron: you

Rich: do you can keep all of the static stuff the Apache PHP MySQL engines, you can keep all of that on a smaller volume that's very well fixed. I hope that ties in with what you guys are talking about.

Cindy: I want to clarify.

Rich: but all

Cindy: I just wanted to clarify one one thing though Meza does not use Docker. Not that I'm saying that a solution that we have needs to but just for the purpose. No. No for the purposes this discussion

Yaron: it

Cindy: it you you bring your own VM and then use ansible to to

Yaron: okay. I thought ansible and docker.

Cindy: Deploy everything on. Mm-hmm.

Yaron: I covered. Okay. Gosh, I really okay.

James: There was there was briefly.

Cindy: Not that it matters because we don't.

James: there was briefly a

Yaron: Oh.

James: something I think maybe memcached that something we installed with Docker like on the rather than installing the service directly. We used Docker, but I've just found over a long period of time that Relying on Docker versus system D was a lot less stable. And so I removed that.

Yaron: Okay.

Cindy: get again not you know Docker is one of the the tools that we're thinking of having in our tool belt, so we're it's not that project can ask the needs Docker, you know, but if we're considering Mesa versus Lexus data specs system builder

Lex: It's not okay. Yeah.

Cindy: Yeah. It it's just a point of information that Mezza does not it does not use

Yaron: Yeah.

Cindy: docker.

Lex: but it

Cindy: It's not exciting.

Rich: safe

Lex: You know, very importantly, I do not promote, but the data specs system builder. That's a very Junior messy untidy project. My point is, you know, Rich, there's one thing about Meza. I guess, as I understand it, you have to have ansible installed And properly configured on em.

Rich: It so if you guys go to the Mezza landing page on media with me and you look at the installation page the installation instructions. The first line is the getmaza script and the getnasus script does the installation and configuration of ansible. It is literally a three. There are three commands and you have any to sit back and let it do its thing and when it finishes and 15 minutes from a brand new install you just You had everything we can figure.

Lex: and, Yet. And you never thought that ansible was brittle.

Rich: I'm not sure I follow.

Lex: You know, I mean I had ansible if a download time's out it will stop. Then you have to make sure that all the ansible playbooks are absolutely item potent wherever it breaks. So I'm you know I I take on yaron's original mission statement that is make it as simple as possible and I'm a big ansible fan, I love ansible but it's not the simplest thing to use. It is simple to use. In terms of you can learn it very quickly but you have to sort of pamper it, you have to be next to it and and hold its hand. And if it breaks, you have to make sure you really understand where you should pick up again. For example, my answer books, I use a whole bunch of tags and I just comment out the tags that ran successfully because I don't want to rely on whether I have actually made sure it's item potent. So, That's why I'm with ansible in in yaron's mission statement, I'm a little wary. That's the that's the reason.

James: so the way we've got it set up is

Rich: But okay.

James: basically the mezzo repo runs a bunch of check Builds on all commits on Travis. So like every line of ansible gets run on every commit likewise. We have it configured. So another big thing I think probably is maybe this is already listed in your Mission statement or whatever, but in addition to just getting a server or cluster, whatever up and running. it's also like keeping it running and keeping it well maintained and a You know good configuration managed sort of way. So the way the way we're running for our production Dev and in servers and and this is not part of the three line Mesa, but it is outlined in the docs. The way we're set up is we have a couple of config repos internally like within within our line our firewall. That basically changes in those. the servers that are pointing at those particular branches within those config repos change automatically. So like we have a Dev branch of our configuro we decide we want to try something new, you know, we want to get the latest cargo version or whatever we bump the cargo version number in our config Dev deploys automatically that runs every every line of line Mesa, but it is outlined in the docs. The way we're set up is we have a couple of config repos internally like within within our line our firewall. That basically changes in those. the servers that are pointing at those particular branches within those config repos change automatically. So like we have a Dev branch of our configuro we decide we want to try something new, you know, we want to get the latest cargo version or whatever we bump the cargo version number in our config Dev deploys automatically that runs every every line of ansible. That's within the Mez application. We decide we like that. We merge it into gets it as well had deploys 30 minutes later. We're good with that and then we're like, okay great we want and I'm production the servers that are pointing at those particular branches within those config repos change automatically. So like we have a Dev branch of our configuro we decide we want to try something new, you know, we want to get the latest cargo version or whatever we bump the cargo version number in our config Dev deploys automatically that runs every every line of ansible. That's within the Mez application. We decide we like that. We merge it into gets it as well had deploys 30 minutes later. We're good with that and then we're like, okay great we want and I'm production the servers that are pointing at those particular branches within those config repos change automatically. So like we have a Dev branch of our configuro we decide we want to try something new, you know, we want to get the latest cargo version or whatever we bump the cargo version number in our config Dev deploys automatically that runs every every line of ansible. That's within the Mez application. We decide we like that. We merge it into gets it as well had deploys 30 minutes later. We're good with that and then we're like, okay great we want and I'm production the servers that are pointing at those particular branches within those config repos change automatically. So like we have a Dev branch of our configuro we decide we want to try something new, you know, we want to get the latest cargo version or whatever we bump the cargo version number in our config Dev deploys automatically that runs every every line of ansible. That's within the Mez application. We decide we like that. We merge it into gets it as well had deploys 30 minutes later. We're good with that and then we're like, okay great we want and I'm production the servers that are pointing at those particular branches within those config repos change automatically. So like we have a Dev branch of our configuro we decide we want to try something new, you know, we want to get the latest cargo version or whatever we bump the cargo version number in our config Dev deploys automatically that runs every every line of ansible. That's within the Mez application. We decide we like that. We merge it into gets it as well had deploys 30 minutes later. We're good with that. And then we're like, okay great we want and I'm production we merged it into prod and And then at seven o'clock that night is our beginning of our production deploy Windows like everything. It's super config managed if any issue

Lex: Okay.

James: happens on our on any of our servers or like, okay well What commit to either meso or config caused that issue? You know, it's is it completely bulletproof? No sure. There's sometimes, you know, we'll not realize that some. change to Mezza rolled the ansible version and now Some conditional task that ran on one

Lex: Mm-hmm.

James: server not another, you know. Runs into problems, but I mean that's that's code. Like what's gonna happen anywhere? That's way better than writing shell scripts. So yeah.

Lex: Okay.

Rich: What James thank you very much for adding that I would only like to comment that specifically the things James mentioned are things. I think their best practices that he and his group are doing and I don't I don't believe that you tell me if I'm wrong, but I don't think you get all that as part of music.

James: You get all that as part of Medicine.

Rich: Okay.

James: Look at the docs read the read the

Rich: it's kind of like you're

James: auto deployer subpage in the docs.

Rich: okay. That's really cool. Thank you. That's great.

Bryan: Really quick. So there's two things that just in the chats that we could point to and somebody could go. test out right lexes and Meza and in the notes all capture that but is it possible maybe to enumerate all the options and provide like testable downloadable paths that we can all play with and see you know, why each one is used and how and

Yaron: Yeah, that would be great Brian. I get I mean at let me know if you disagree but I think it would be great for for the people from Hollow velt and Mezza to add to that. The Wiki page if I mean, I think that would get it what you're talking about. Assuming assuming. They think that these are actually good Solutions. I haven't actually heard anyone say yes, we think the blue spice Docker installer. Yes. We think Meza would be a good solution for this for this problem. But assuming anyone does think so would be be very helpful to have for them to add to that wiki page and you know doesn't have to be the same level of detail that Lex has but just something listed, you know, listing equivalent information for those

Markus: Yeah, I'm so far away. I can say I can do that. Actually to me it seems like after this discussion that the various approaches are not actually competitors but we are tackling different parts of the whole picture

Lex: Exactly.

Markus: in different detail and I would like

Lex: Yeah.

Markus: to so in my in my Visual mind in my mind, I see this image of like, having trying to having a compound of different solutions somehow, as if it makes sense. And, and that is something I have to think about, I guess we all have to think about, but don't think of it as a we take the blue spice solution and then that's it. So I think that's not the correct way to think about it. We should say. So which aspect is tackled best by which of the systems in camera. Learn, can we integrate from those?

Yaron: Sure, but still no I I agree with that and of course, you know, if something if Mesa say works, then you can obviously just do this on with Meza. I mean you can do this right now, but just in terms of you know some some some standard solution that we've put out and say this is what we recommend that this is what we're using for these semi-official products now, I think it I mean you have to start with something I think I mean, yeah, you know, obviously then you we

Markus: Right.

Yaron: everyone can work on making it more like something else. But yeah anyway.

Lex: Yeah, can I comment on what Mark has just said? You know, there's some consultant lingo here because the goal is to have it me. See, which is mutually exclusive collectively. Exhaustive So we should, we should separate this challenge into into components that don't overlap, ideally, but together. You Know, cover all the aspects. And that's what I'm what I mean when I, when I'm insisting on this abstraction layer question, it's not so much the implementation. It's where goes what? That is really the, the challenge right now. So and and that's my contribution here with media, he can ask us that. It's it's one aspect and I've separated it out into several aspects. Just to have a, you know, a basis for discussion.

Bryan: Yeah, maybe to include or update what I was saying on that page. Maybe it is the Canasta infrastructure page that we could have. You know, what what you're trying to solve. You know, like where where is Mesa City in here? And then you know Lex would say kind of where where is you know system builder kind of sits in that and what it's not trying to do.

Yaron: Yeah, I mean, I think that I don't know if this is what you're getting at. But the thing that page should be updated. I can update it to to reflect to indicate. This is only this this part is only about taking Code Media Wiki installation already exists and turning it into an image and the part about creating the the installation the first place using composer. Anything else is a separate component. That should also be discussed but it's but ideally that's our, you know can ideally it's two different processes to do those different things so that to make it more modular. Yeah. All right.

Ad: Okay. I think there's one thing to add that this not only what you have to do, but also when some things you only do once and after that, you start upgrading and then you start. So there's also The question about what is the rhythm of the different? Activities. Is that? So that's also that's also a reason.

Lex: Well.

Yaron: Okay. Bye Marcus.

Ad: To separate things by Marcus. So I'm going to

Yaron: What Lexus the explanation definitely ties into that he has a whole

Ad: Yaron: separate.

Ad: He has a whole separate. that.

Yaron: section about upgrading versus

Ad: Section about upgrading versus

Yaron: installing

Ad: installing, but you are upgrading is also on different levels. I think. And and also depends if you have a farm it's Meza is is about Farms, isn't it? Corn, not only about Farms.

Yaron: I think it's well.

Bryan: Richard James

Yaron: I think it's not only about Farms. But okay,

Ad: and,

Bryan: Yeah, I mean.

Ad: and you can,

Yaron: Okay, well.

Ad: Okay. Well yeah, but there's something I'm going to

James: Yes, so it makes it makes multiple

Yaron: it

James: wikis. So and you get a landing page. I guess that makes it a farm.

Yaron: Okay, I guess it is about Farms.

Ad: Okay.

Yaron: All right. Okay. Well we want to have the people

Ad: Yaron: already. um so I guess this is a good place to

Ad: I guess this is a good place to and

Yaron: and the this meeting.

Ad: the meaning.

Yaron: Yeah, okay.

Ad: Yeah. Okay.

Yaron: Well, this was productive.

Ad: Well

Yaron: And hopefully people from

Ad: And hopefully people from

Yaron: and hopefully people from least Mezza

Ad: and hopefully people from least Mezza

Yaron: and blue spice will add something to

Ad: and least spice will add something to

Yaron: the wikipage page based on what we

Ad: the page based on. What we discussed.

Yaron: discussed. And I guess we'll meet next week.

Ad: And I guess we'll meet next week.

Yaron: I was hoping this week would be this

Ad: I was hoping this week would be.

Yaron: meeting would be where we

Ad: This meeting would be

Yaron: meeting would be where we

Ad: This meeting would be

Yaron: meeting would be where we

Ad: This meeting would be

Yaron: meeting would be where we

Ad: This meeting would be

Yaron: meeting would be where we made and

Ad: This meeting would be where we kind

Yaron: kind of decision but you know.

Ad: of decision, but

Yaron: hopefully next week is

Ad: Hopefully, next week.

Yaron: that when that happens Yeah, I mean anybody want to add

Ad: Yeah, I mean anybody want to add anything?

Yaron: anything. All right.

Ad: All right.

Rich: Thank you.

Yaron: Okay,

Ad: thanks, you're

Lex: That's it.

Yaron: Yeah. Yeah. Thanks to everyone. What?

Lex: And no I I well, you know, after the official conclusion of the meeting, I like to ask Brian, whether he has tested out the the new install.

Bryan: I know but I'm I have it sitting here waiting in case we're gonna do the demo for it, but

Lex: Okay, yeah exactly. But just let me know whether

Yaron: Oh, yeah.

Lex: especially also The Rustic backup and And restore.

Bryan: well, I'll Google the world in what I think of the just Guam in on what I already said. I just think it'd be cool to understand kind of which. Which problems each you know solution is trying to address having that kind of clearly written out for for people like me to understand and then you know being able to test those things to see so I'm happy to like provide VMS to anybody. I think everybody in here has the ability that themselves but I can you know give you a key to Centos and let you put in the three lines you can run Mesa or whatever, but I think it'd be good for everybody to kind of see what each thing is doing.

Yaron: Yeah.

Lex: Okay. yeah, but then you know

Yaron: Yeah.

Lex: be productive. Now I'd like to just restate what my intention here is. It's the original installation that the simplest way to perform an original installation and for me the that's just copying the The the archive and and then setting it up because ideally that way of installing. It has no ramifications on how it can be managed afterwards. Right? Because as we said, we want to we want to build a bridge head at the customer's site and convince him you know that that it's good. It's a good idea to use media Wiki and and for that, you have to remove all the obstacles that are in like impediments to to to set it up on on site. So my but that's actually my My intent here just to make that. So it's a narrow place it's just the simplest way of installing it. And then managing it is, can we? We will have to look into this. And building the package. As I said, the data spec system builder is certainly not the best approach for that. It's a messy thing needs a lot of attention and love and care.

Yaron: Okay.

Lex: but,

Yaron: well now okay, I was gonna say at least you support your own system, but now it doesn't sound like no no

Lex: Well, no, I of course I do.

Yaron: just

Lex: But, you know, I, I can't tell you now well just clone get the the data spec system builder and and hit some, some shell file and then you will be happy, you will probably not be happy because there's lots of tricks you have to apply to make it work. But but it's it's a it's a factory that builds an artifact which is an archive. And that archive is then used by what I create now at media Wiki Canasta and installs it. And you can see from the repository, that's a rather simple process.

Yaron: okay, you were just talking about this data spec system builder, but media leaky Canasta is something is

Lex: Okay. Yes, yes. No, that, yeah, yeah.

Yaron: that you would

Lex: Yeah, yeah. And I I tested that with. So Brian was my test user and it actually the very first time it ran there. There was no So there we got that quality metric in. In place.

Yaron: Yeah, okay.

Lex: No.

Yaron: Yeah, that's great. That's a you know, it's it's good. Yeah, it's great that the test worked and you've one happy user already, which is really good.