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

[Perry N. Myers]

Jeff Schroeder wrote:
[snip]
> 
> 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.

Embedding in firmware could be an option, if the firmware sizes grow and 
the image sizes shrinks and there is a good place to meet in the middle. 
I'm more of a fan of embedding on system flash, in which case it's a 
tradeoff between cost of image minimization vs. size of the flash you need 
to include.  One could make a good argument that once you've decided to go 
with flash anyhow, paying for 64MB vs. 128MB flash is negligible.  But 
then again, I know nothing about managing hardware on large scales.

But you bring up a good discussion point, I'd be interested to see what 
others weigh in on here.

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

Not taken as such.  It's constructive discussion.

Perry

-- 
|=-        Red Hat, Engineering, Emerging Technologies, Boston        -=|
|=-                     Email: pmyers at redhat.com                      -=|
|=-         Office: +1 412 474 3552   Mobile: +1 703 362 9622         -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|