 My name is Adam and this is a minimization talk and So I was minimizing my system and I minimize it so much that there are no funds left. So everything is handwritten on the slides So One of the points I want to make here is that smaller might not necessarily mean better. So If you minimize the system that there are no funds left. Is it better or is it worse? I don't think it's better. So Um, that's just something to keep in mind, but let's just start with the problem So what's the problem with with like I'm trying to solve? So the problem is that things are getting bigger and that means that some container images are getting bigger and some Applications or run times and their dependencies are also getting bigger And that's just the fact that we have and why is it problem? So There are like four things I've identified maintenance footprint. So if there are like more things you need to maintain more things, right? The attack vector is also a thing because if they have many dependencies on your system There may be more vulnerabilities It's less flexible because things can overlap and what I learned just today that some IoT devices that have very low bandwidth connection Getting updates there might take time. So minimizing is also relevant in that use case a lot but as I said bigger is not necessarily always bad And I have some examples here. So like on the left I have Small base image, which is like maybe container image and some applications on it and on the right I have bigger base image and smaller applications and if you have bigger base image And if you have that in the cloud and on a bigger scale The base image will share things with for all the images. So like the total size will be smaller So bigger is not necessarily better in this in this example But on the other hand If I have a smaller base There's less things. So it's more flexible because whatever I put on this It could work because I can track basically anything but in the other one I would have to replace packages and so it's not always the case If I have something like this if I have like the base and the applications and there's some space in the middle What to do like so at the bottom, right? That there's pieces like everyone wants jillip see for example in the middle There might be things that someone wants and then like just the application and I could just make a cut somewhere But that's not really a minimization like that's not optimizing anything that's a very different conversation a very different decision and That's basically something. I don't want to really really solve so about smaller images. I This effort will be enabling building smaller images by optimizing and by making things smaller It will be informing decisions to make smaller images. We can say this package for example is very popular But this other one is not but we won't be defining smaller images. So In these are not really focused here. So So what's the focus? What's the goal? so The goal is really to optimize use cases and by use cases. I mean applications and run time Deploying in certain contexts. So like web server in a container or something Whatever is useful and we can then focus and try to make its try to minimize but Keep it useful so we can look at multiple things like dependencies features or Alternatives and I'll just demonstrate what that's what all of that is so if I have an application and There's a lot of dependencies, right? And I it can happen that something was just dragging by mistake or Maybe there was something forgotten and just dragged too many things so I can just cut it in half And maybe it'll continue working So that's like the easiest thing that we can do and I'm sure there will be some of these some of this existing What we can also do is that I have an application and maybe for my use case I don't need all the features of the application So I can just cut some of the application out and it might minimize things that's an approach as well or And this is what's what might be happening a lot is that If I need certain functionality There might be a different provider of the same functionality in the repos So I might be able to cut like those I don't know 17 packages and replace it with other two and that might happen as well And with all of these data, we might be able to look at things in bigger context So I can have a look at multiple multiple applications or use cases and see Make some statistics. So What's what's in the bay? What could be in the base and I can use that? Do I can use these data to? Give it to the people who actually care about containers or actually will be doing smaller images. So like I can Minimize things and get some data from it So before this objective started There were already people doing minimization things and How we can we help them so? Because this is nothing new like there are all the people doing this So how can we help and how can we make it on maybe on a bigger scale or? with bigger impact so First thing is making smaller versus keeping smaller and I think we need to do bit of a both But just like doing there and minimizing things and hoping they will stay small that one happens So we need to have some kind of balance between these two The same with doing versus automating I can do something or I can automate Whatever is possible again. I can't just automate. I need to be doing something first. So I know what to automate so But but tools and automation will be one of the focus here. And that's the new thing and I have Something about graphs. So these are like dependency graphs. So we can look and add the repos and see all the dependency relations in a in a federal repo for example or I can have a look at a specific installation the specific use case. So let's have a look at both. So This is the federal repos It took three hours to generate is 130 megabytes SVG file with 1.6 million lines It took me like five minutes to load in a browser and this is not good for Humans and not good for computers. This is like really hard to process already hard to work with so I don't think this will be the It's nice to look at it's interesting, but I don't think it's useful. So that's what we're gonna do. So Let's have a look at the installations instead and maybe we can consume information from the repos later and Where I have a demo I managed to prototype a tool that can visualize some dependencies It's an early prototype, but it might be useful even now and we can extend it with things. So This is a demo I'm so I'm opening a terminal and the tool is Just called show me and I can do Help and basically what you need to do is show me what how and where So let's have a look at the federal base image content base image. I just say Show me federal 30 graph And I say where that'll be an SVG file and it's just processes things and There we go, and I can open the SVG file in a Firefox for example, and this is it. This is the federal 30 base image It's not ideal, but it's much more readable, right and we can see Julie see in the middle So what I can do is I can click on any of the nodes and see the relations between the packages And I have like red arrows that means that and I can be the package from here But the RPM build lips requires a lot of packages and it's required by one And what I can use it to is just to do a quick inspection of like what's coming on So if I want to trace down the package on the RPM build lips so I can Follow the blue line and it's just required by Python 3 RPM, which yes again just one line Why by Python 3 DNF I Click on that again one line. It's like it's been chosen for a demo required by DNF and so on and This can give me like a very quick overview why something is is in the installation So Yeah, this is just a simple view of of the dependencies. I can click on jellybc because everyone wants to see it I think everything on the screen requires jellybc except one package somewhere there all right, so So that was a view on on a on a specific image But again, that was just too many things and maybe not useful like for for looking at it So let's have a look at HTTP on top of that base image. So first of all, I'm gonna do I'm Build I'll build an HTTP container So I'll just say that I want to use the 30 that was a base image. I only install HTTP and let's see what happens and there we go and I can just Use the same command Actually, no, I won't use exact same command I will use this specific option and I will say that I want to find package group and I want to merge The whole base image into a single node that gives me a little bit better view. So I can do show me HTTP F30 graph and I'll define the group. I've called it F30 base image and it's from the container Again, in general as a SVG file, I can open it with a Firefox and there we go. This is much simpler view and If I click on the federal base image, I can see much simpler view Maybe in this simple view I don't need like all the clustering in there and I can have a different one. So let me Change that to a directed graph instead of Home as you think So I just change this graph to directed graph and this will be much better view Open a Firefox and I think this is much more readable just to see on like what HTTP looks like on top of the base image I'm sure some of you can see a bug. There are two packages on the left that are not pulled in by anything That's because this doesn't show any weak dependencies But that'd be quite easy to fix and they're pulled in by the other package So that's how I can basically visualize this It can work with other things not just containers it can work with Parts on your system even your own system. So what I'm doing here is just I'm installing a package into an empty route And I'm going to visualize that and there's one more feature. I'm gonna show you That was super fast I think video is great All right So I'll say show me and I can just do a path and it recognizes the path and shows the path and there is one new option I'm also using each that is dash dash slide size and It with every package. It just also shows how big it is on the system Which is useful to Maybe see like if there's something big I Should maybe focus on so that's the it's like low barrel packages again It looks very similar And you live see All right, so like in this I haven't minimized anything But maybe this tooling might be helpful to someone and probably not to use it in the in in the scenario as I was on Image that has been already produced them might take Days to to produce that feedback might not be that useful But maybe if we run it for in the federal CI or as part of the Gating or whatever in Fedora, we may be able to generate that for Builds that we want to focus on and we might be able to generate these graphs. You might be able to generate size changes over time and If the size goes of something goes up the threshold, I can just do an alert And that's how we can maybe monitor and try to keep things smaller over time But that was just like really abstract I have enough roadmap as well. So what's the plan for the future? I Have Four stages and the later two are a little bit fuzzy, but the first is discovery. So first we need to see what's going on and Basically do discovery Experiments that's the next one and then I have stabilization and integration We'll see what's gonna happen because the first will inform the other one, etc So this is a timeline I have this is the probably most specific timeline right now we're in the discovery phase in August and What we need to do is to have some sort but more specific plan for the next phase so we can do actually some experiments, but Because we shouldn't just get random dependencies. We need to know what to do. That's why discovery first um If anything of this is interested for you You can join the team. We're very welcome to join the team and a few people already did that If you searching for information, you just open the thorough documentation you can click on engineering teams Click on minimization objective and that's all the info there as the actual objective page There's an action plan for Mostly the discovery phase or like a short action plan have for focus areas that you can read about There's a team Or a 10 people in the team interested in doing things About minimization and there's also link at the tool in the tool section and this space We basically growing and having more information as we go There are some links Inviting is right. So sorry about that So that's a documentation We chat on the federal develop and this is our issue tracker and if you have any questions If there's a space for policy change in fedora, definitely. Yes That's already a lot of policy about making Making minimal things and it's more might be more about enforcing but I haven't seen all the policy and there's definitely space It's not just yeah cutting things off, but making sure that it's It stays like over time so policy is definitely in scope Yeah, if it's runtime or build time primarily event time because that's what matters for the installations but Yeah, basically, that's the primary focus runtime Yeah, so if there's a folk if there's a focus on Sub packages as well. Yeah, so on the graph these were binary packages from for the Russell These are basically the sub packages. I think what you mean is if you have infrared source RPM package It has multiple you can have potentially multiple binary packages in there and that's what the graph shows. So, yeah Oh, yeah. Oh, yeah So maybe if there are like multiple options, the tool could suggest alternatives And that's definitely the plan that could do that like, yeah That's why I want to focus primary on installation So the initial graph is much smaller than the repo that was basically unreadable, right? But it can consume the repo data and show you alternatives like yeah Hey, this package drags in this but like there are five other options and you can instantly see the impact It's definitely not implemented, but it's something that you would be interesting helping I would be very happy to have your board. Otherwise. Yeah, I think that would be very useful Yeah, so I said I want to the question was that I said I want to add features But that's in conflict. Some people want small some people want all the features so what to do with that I'm that's what I want to focus on use cases and not necessarily packages of the necessary all the all the ecosystem and It'll depend case by case But we definitely like if there if if we discover that for example, and I'm just making this up We have two use cases for HTTP one full featured on one very small we can build two versions of age two variants of HTTP D with different feature sets like that that's not a problem I guess so yeah, that would be the that would be the That would be the option. I don't know if that happens ever But yeah, that that basically would be the solution there So the question was if if we get to the point that we have alternative variants of packages with different features if we can have an install image with those Maybe yeah, like giving them options. Yes, probably but that would be very very later, right? We first need to make it happen. So we first need to discover like what's what the focus would be Then actually minimize it and produce it and then in the end Yeah, maybe make the installation easier by giving people better interface, but that would be very very later But yeah, it could be could be not now not this year probably but like could be So the yeah, that was mostly remarked that we have some like cruel or cruel minimal and There's a problem that if you install one into a Docker image you can To a container image you can easily switch to the other one. Um, I don't think that's a Problem that much like if you can achieve that state That's fine. And if there is a use case for switching from one to another, maybe we can work on that, right? But I think first first we'll be enabling this and I'm happy that there are already cases like that but Yeah, we still need to do the minimization work first and then I think worry about Switching from variants and things like that, but if it's a use case, it's a use case. Yeah, it'll be Happen. Yeah. Yeah, I agree with you. Um, it was about um, yeah We have container image federal base image that has a certain size that has full featured package If we switch the full featured package to something limited it'll be smaller But some people couldn't be able to use it and this is exactly what I want to don't want to focus on container images It's a very different job than this. I want this to be focused on actual Minimization of those use cases and then deciding what's in the base image and what's not that's a very different Thing and we have a container second federal that but yeah We can give them data like I can see I had I had the screen with like Multiple apps and like what's what's the intersection in there? Like what's the overlap and we can say hey this package is used by almost everything So you should have it in the base image this one isn't so you might not be there but it's up to you to actually decide and Who knows like you might have multiple Base images in Fedora anyway, right? You can have very small one for rust applications because you don't need almost anything You can have a big full feature one for other deployments. I don't know um But I guess that's the container sick any other questions RDS ideas comments. All right. Thanks for coming and enjoy the boat