On Thu, Mar 6, 2014 at 12:13 AM, Don Zickus <dzickus@xxxxxxxxxx> wrote: > On Wed, Mar 05, 2014 at 10:02:17AM -0500, Josh Boyer wrote: >> On Wed, Mar 5, 2014 at 9:54 AM, Don Zickus <dzickus@xxxxxxxxxx> wrote: >> > On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote: >> > For example, lets start with 100MB package requirement for the kernel (and >> > say 2 GB for userspace). This way the kernel team can implement >> > reasonable changes and monitor proper usage (because things grow over >> > time). >> > >> > If later on you realize 100 MB is not competitive enough, come back and >> > chop it down to say 50 MB and let the kernel team figure it out. >> > >> > But please do not come in here with a 'every MB counts' approach. It is >> > not very sustainable for future growth nor really easy to implement from >> > an engineering approach. >> > >> > Is that acceptable? The kernel team can start with a hard limit of 100MB >> > package requirement (or something reasonably less)? Let's work off budget >> > requirements please. >> >> This is a fair point. To be honest, I've ignored the "every MB >> counts" aspect entirely for now. I've instead been focusing on >> required functionality, because that's likely going to be the main >> driver of what the resulting size will be. That's the point, we want a reasonably small package while still providing the required functionality. Not sure how providing a fixed size number is helping in this. But most of all, I didn't throw in a number because I have no idea what is reasonably possible. I really only just said "every MB counts" because the question came up before (in Josh's old thread) and I hoped I could stop this discussion from happening again before we have any numbers for this. > Of course. :-) > >> >> FWIW, the existing kernel package installed today (a debug kernel >> even) is ~142 MB. 123MB of that is the /lib/modules content. ~6MB of >> that is vmlinuz. The remaining 13MB is the initramfs, which is >> actually something that composes on the system during install and not >> something we can shrink from a packaging standpoint. > > It also helps with monitoring. 3-4 years from now after all the chopping, > these pacakges bloat right back up and everyone forgets why we chopped in > the first place. Hard requirements help keep everything in check and > forces people to request more space which the cloud team can evaluate > properly and still control their enviroment. Well, if we can remember why we put up a fixed size requirement, why can't we remember why we did the chopping? ;) Anyway, I think it's fair to define a "kernel-core should be smaller than X MB" requirement but I don't think it's fair to say Y MB because I like the number Y. I also don't like that we might throw out e.g. NFS just because we're 1MB over the limit. But if it helps the kernel team to have a fixed number, someone tell me what we roughly save by throwing out the stuff we discussed and we can discuss what number would long-termish make sense, I guess. Also, I'm not sure whether we should measure the extracted files, the compressed RPM or both. -- Sandro _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
