[colug-432] Red Hat in May

[Rick Troth]

On Fri, Apr 19, 2013 at 4:33 PM, Neal Dias <roman at ensecure.org> wrote:
> I can't really speak to the product since it's debut after I left Red Hat,
> but I will say that from my personal observation, Red Hat really tries to
> use open standards and protocols whenever possible.   ...

Neal, thanks for chiming in.
If I struck a nerve, I did not mean to.

My life is in "z space".  APIs and protocols which work fine for Xen
and KVM or for VMware and RHEV may fall flat when talking to z/VM,
even z/KVM.  It's hard to be architecturally agnostic, even though
many of us try diligently.  So I'm really really really looking for
APIs and protocols which are common to any virtualization on any
hardware.  I'll be (pleasantly) surprised if MIQ is completely
"there".

But please understand, I'm *excited* about it and planning to shove
aside important prior commitments to be at the MIQ presentation.

Simple stuff like the ability to script cloning or (virtual) hardware
changes ... we're talking from the command line ... doesn't usually
show up.  Sure, VMware will make a virtual CD appear when it wants to
install its own driver.  But what if the customer wants to do that?
(especially apart from the GUI)

Nominally related, there is the up-coming "VM and Linux Workshop".
This year it will be at IUPUI.  I believe RH is represented.  I do not
believe MIQ is on the agenda.  (RedHatters, drop me a note off-list if
there is interest.)

I count five thriving architectures for Linux these days: x86, ARM,
S/390 (aka "z", where I live), PPC, and SPARC.  (This last one may not
count as "thriving" but Oracle keeps talking about it. And I probably
missed another.)  Of these, about 80% support some form of
virtualization.  How they do virtualization varies.  How they
interface with hardware varies.  (Emulators don't qualify.  That's
different.)

>   ...   I've
> been an advocate of "roll your own" management solutions such as
> cfengine+SCM+kickstart etc.

Mee too.
Serious long term presence of any product or application requires that
it integrate with the customer's operation.  So there's *always* some
amount of "roll your own".  (And there's always back-pressure to
minimize customization to ease upgrade pain.)

Neal's discussion about RHN sounds like what I'm talking about.


--
-- R;   <><