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

[Jeff Schroeder]

On Mon, Jun 30, 2008 at 5:30 PM, Perry N. Myers <pmyers at redhat.com> wrote:
> 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?

Maybe that should be ultimate question number two...

The ultimate question seems like, "Why do we need the node to be so
small in the first place and
is it really worth it to keep pushing things smaller at the sake of
usability?". Are you guys looking
at running nodes in firmware or something? 60MB seems awful hefty for
that goal and flat out
unreasonable in most cases. PXE booting a few hundred megabytes seems
perfectly reasonable
even if a bit big. What does being smaller _really_ buy you?

After that question is realized your question applies.

KISS is good, but if being small inhibits a user from properly
troubleshooting a system the project
has failed them in one aspect. How can oVirt save it's users time and
stay out of their way? How
can using oVirt give me more time to go on vacation? How can oVirt
help me get this crazy infrastructure
back in check? Those are questions we should ask. Is getting an image
< 20MB a "worthless microoptimization"
as danpb so eloquently put it? Or is there something that necessitates
it? If there is please enlighten me.

Getting in user's way is certainly not a way to win friends.

<disclaimer>
Please don't take this as a rant or attack. It is meant to start a
constructive conversation.
</disclaimer>

-- 
Jeff Schroeder

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