 OK, it's recording. So sorry, we skipped the first 15 minutes because that was the perfect timing for I turn and myself to recap on this topic and see what was the original problem, what could we solve last week, and where we stand if we can go further on that. And the question from Todd was actually related to that. Can we go a bit further on that without asking the users to provide information or to provide a better image? So my answer, quick answer, is not at the moment because for one reason, we don't know in the pipeline what is the job that is going to be the one for building the project. So we are missing one of the pieces of the big puzzle, the bigger puzzle, to go one step further. We need to identify one job, one specific job that could be reused, and we don't have that information. That we're required to modify the CI configuration and all that kind of things. That's why we are not there yet. The solution that we found last week, just for the record, it's backward compatible with what we have today. And it doesn't require us to update GitLab itself or the runner. So we don't rely on any other team. I think I've got that down to the answer now. Way to identify it. And so we also talked about maintenance and actually this new version using the user image would not require some maintenance on our side. Apart from providing packages for our tools, but that's all we don't need to provide packages for all the architectures or whatever. Even if we have to do that, that could be automated very quickly. But we don't have to create one image for Java 11, and that, and that, and that, and Java 12, with that, and that, and that makes it for creating a huge matrix where we get lost very, very quick. And so at that point, I guess we need to figure out what would be the next steps. That's what I added in the doc, not in the doc, in the issue. And so I asked Fabien Cato, who is one of our staff engineers in the team, to take a look. He was pleased with the solution. I would be pleased to have someone else with a technical background taking a look just to make sure that I didn't miss anything. I don't see any blind spots in this proposal, but we never know. Before rushing into saying to customers, we have a solution. It's going to work. That would be the worst scenario ever. And we'd probably, the next step for me would be probably to have a POC adding a kind of small photo time to demonstrate that it's working out of the box. It canceled one of the reward programs that we had out there. So we need to identify also one of the reward programs that we have. And currently in the test projects so far, it was working out of the box because there were just two simple solutions. Find something that would be a bit more complex than that. And what the new proposal is, is that going to be, I assume that's going to be a type of MVC. And from there, is there, do we have any concept of growth or what something to delight the customer with this would be? It's a kind of MVC by itself. The missing part that we don't have today is the ability to install all packages into the provided image. So for that, my recommendation was to use some system packages instead of something based on Curl, for example, that you would download, especially because most of the Docker images out there, they don't have Curl installed by default. So that would create one extra step for the users. Having some system packages would work. But most of the images outside are based on Debian or Alpine. So the MVC for me would be we support all images based on Debian first and second iteration. We also have the packages. If you use Alpine, we have the packages for that. So we can split that in two iterations because we try to have really the smaller change possible in each iteration. So that would be that. If we have that, we can have something working real quick. We can have a POC as well. And we can ask users, especially your customers, could you try this solution with your specific environments? One problem that we will need to solve as well is license management because it's something very specific. We rely on a specific tool where it's license finder and they try to solve that problem by having a gigantic Docker image where you have Python, Go, Java and stuff. It's more than three gigs and it's not even working. The customer that we are talking about at the beginning of this meeting is complaining that license management is failing after a long time of processing. It's failing for this project. So we decided to use something else which is not really far from what we envisioned and now it's working. So we can, we will have to update heavily, I guess, license management to support this kind of scenario. And the final image would be a lot more lighter than that in today. I guess, thanks for joining. Yeah, sorry. I had a surprise delivery when they tell you there's a window between five hours where something will show up. Yes, we have that as well here. It's not a window, it's a, here in French we would say it's a fork. You have a fork of hours and when they start delivering it's not a fork anymore, it's a rake. No worries. So we are at the point where we use the first 15 minutes we start with to sum up where we are to give some background and some insights about where we are coming from because we started this discussion a year ago already. And we covered the point where can we make that a bit more automatic so that the users want to matter about providing their own image and I don't see how we could do that without being able to point exactly this is the good job and this is the one that the kind of image that you need to reuse to run the analyzers. And I was talking about license management which is very different from the others because they try to solve this kind of problem by having this gigantic image where they put every language in every framework with the foots in there and it's not even working. If you don't have the right version of Python in the image, you're good to have something here on the side. I'm just taking notes here. Great and heavy version is embedding all languages and frameworks even working. And so I think we were also telling that the next step would be probably to have a POC. Starting to prototype that, you said that we need a real world example. If you have anything in mind, I remember that this meeting is recorded. So no mention of customers. Yeah, I think that's what we do have. We do have one that we discussed last time. That's an option. And so that would be a Python example. Python is fun and it's kind of an interesting approach where you take something like a scripted language then you need to compile some native extensions because they don't really provide out of the box packages for some of those popular libraries. So I think that's probably the best in terms of a slightly isolated but complex example. I think the other thing that we talked about before and I think this came up during our conversations today was whether or not we have any data on, we don't have any telemetry or usage pings for the types of analyzers that we're using that are popular in GLab.com. So that can gentrally be worth pursuing. I can note that sometime. So one of the difficulties I guess to start prototyping is to add this injection system. But my suggestion was to use packages, system packages like DBLI and DGAN or L-Python packages. If you have any better idea, I would be glad to hear that. But we were talking about MVC as well and that could also make the first MVC a bit lighter. For example, we would say we only support DBLI based images and next month we're going to support L-Python as well that could give us some more time to package and product package a bit better. I knew a few tools that we could use to cross-compile and to create or even RPMs for packages for relapse-based mis-throws. Do we, what's the advantage of using a Deviant package versus just curling down? Good question. That's a good question. Very simple. Almost all of the images that you will find on Docker app they don't have curly installed by default, nor the AFW get. So that would be an extra step for the users if they want to grab more tools. That's the first point. Second point, if you have a different architecture, you need to date your curve so that you don't know the right package tool. And the third one is it's a lot easier to detect the kind of distro that the user is using. For example, if we know that it's a Deviant flower distro, then we know we can use a DPKG directly, dash I for install and then you are out of the package and DPKG would handle very simple dependencies like we can tell the Python analyzer requires Python. You can say that in Deviant and Python is a meta package. It's not something that you install per se, but if you have Python 2.7 installed, it's going to fulfill the Python requirement. As well as if you have Python 3, so at least you have one Python installed, it's fine. If not, it's going to complain that you have unmet dependencies and it's going to fail, but that's a good failure with an explicit message where you understand that you need to install Python if you want to use the Python analyzer. Okay, that makes sense. Okay, so a Debian package for Python, for our Python analyzer, that sounds like a great MVP target. Yeah, and that's not really hard to, there is, I think it's FPM. What's the name of this generator, FPM, yes. If you provide the project variable to generate all kind of packages. So the point of having this system packages is if you know that it's a Debian-based distro, for example, you know for sure that all the tools to install depth files are going to be there. Otherwise you have to guess and we will run into problems for sure. Another one is, if I remember well, go X. So there are a few tools out there that would be useful for that. No, it's go X, I guess. I'm not sure if it's just a cross-compiler or a package or as well, but there are many for sure that we can use without having to create all the required folders because believe me if you try to create a package for Debian you have to create a bunch of folders, a general, with a very specific format. It's a bit tedious if you have to maintain that. All right, and we are out of time. Sorry, I didn't see that. Any last comments, any complain you want to? Yeah, that's a good one as well. Yeah, all right. Okay, on my hand. Perfect. Todd, anything on your side? No, I'm good for now. Perfect, thank you very much for joining. We appreciate it and we'll see you next week. Okay, bye-bye.