Modular Kernel Packaging for Cloud

[Sandro "red" Mathys]

On Thu, Mar 6, 2014 at 12:13 AM, Don Zickus <dzickus at redhat.com> 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 at redhat.com> 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