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

[Perry N. Myers]

Jeff Schroeder wrote:
> On Mon, Jun 30, 2008 at 5:00 PM, Perry N. Myers <pmyers at redhat.com> wrote:
>> 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.
> 
> 
> <sarcasm>If only there was a way to do automated testing?</sarcasm>
> 
> The Zumastor project (http://www.zumastor.org) has a pretty complete set of
> automated tests here but they run under uml:
> http://code.google.com/p/zumastor/source/browse/trunk/cbtb
> 
> Have any redhat-ers thought of asking for a few boxes to do continuous
> integration
> and unit testing on oVirt? Would it be a good time to consider or too
> much effort to get up
> and running?

We are planning on doing automated testing.  However, even with automated 
testing, testing & supporting multiple node spins will still take more 
time and energy (especially from a support perspective).

So the ultimate question is, what do we gain by splitting up the node into 
multiple images in order to meet an arbitrary size goal?

Perry