[Ovirt-devel] [PATCH] Add additional blacklisting and rpm removal to managed node

[Perry N. Myers]

Ian Main wrote:
> On Mon, 30 Jun 2008 15:16:23 +0200
> Chris Lalancette <clalance at redhat.com> wrote:
> 
>> Perry Myers wrote:
>>> A few important notes:
>>> 1. /lib/modules was scoured for things that didn't seem necessary, however
>>>    my notion of not necessary may not be correct.  Please review the list
>>>    of modules that I'm removing and if you see one that we need to add back
>>>    in, comment.
>>> 2. /boot is removed as we don't need an initrd and kernel image inside of
>>>    the livecd initrd.
>> Ah yes, good to remove this, since it is superflous.
>>
>>> 3. The blacklisting method is a hack.  What we need is an appliance creator
>>>    that has black/whitelisting capabilities...  (hint, hint to our AOS
>>>    friends out there)
>>>
>>> The ISO image RPM is down to 45MB
>>> PXE image RPM is at 52MB
>>> Running filesystem is 130MB
>> My question is: so?  I don't really see how it's much of an improvement over
>> what we already have.  Or rather, it's an improvement, but in my opinion the
>> cost (breaking RPM, breaking RPM dependencies, etc) is too high.
> 
> [snip]
>  
>> Overall, seems to be breaking a lot of debug and reproducibility functionality
>> for very little gain.
> 
> I think we should bring back the idea of having a debug image and a production
> image. Have your cake and eat it too.. might be a bit more to maintain though..
> have to think about that.

This is a double edged sword...  Having multiple image types means that we 
can have custom spins for developers, specific hardware types, etc.  But 
it also means that we need to test -each- of these images.  It's very easy 
to fall into a trap where everyone uses the developer image and then you 
go to release and start seeing unforeseen problems in the production images.

To note: there are no changes in this patch that affect developer 
usability.  I intentionally left in vi, userland utils, sshd, etc...  So 
at this point with this patch there is no need to split 
developer/production images.

However, if we need to minimize further than this we may need to consider 
splitting.

Perry