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

[Jeff Schroeder]

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?

> 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.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com