<div dir="ltr"><div>No nerves struck at all, I'm no longer at Red Hat and have no skin in the game either way, I just thought it might be of interest to hear a little bit of the "internal" perspective. =]<br>
</div><div><br></div>-nd<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 19, 2013 at 5:29 PM, Rick Troth <span dir="ltr"><<a href="mailto:rmt@casita.net" target="_blank">rmt@casita.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Apr 19, 2013 at 4:33 PM, Neal Dias <<a href="mailto:roman@ensecure.org">roman@ensecure.org</a>> wrote:<br>
> I can't really speak to the product since it's debut after I left Red Hat,<br>
> but I will say that from my personal observation, Red Hat really tries to<br>
> use open standards and protocols whenever possible. ...<br>
<br>
Neal, thanks for chiming in.<br>
If I struck a nerve, I did not mean to.<br>
<br>
My life is in "z space". APIs and protocols which work fine for Xen<br>
and KVM or for VMware and RHEV may fall flat when talking to z/VM,<br>
even z/KVM. It's hard to be architecturally agnostic, even though<br>
many of us try diligently. So I'm really really really looking for<br>
APIs and protocols which are common to any virtualization on any<br>
hardware. I'll be (pleasantly) surprised if MIQ is completely<br>
"there".<br>
<br>
But please understand, I'm *excited* about it and planning to shove<br>
aside important prior commitments to be at the MIQ presentation.<br>
<br>
Simple stuff like the ability to script cloning or (virtual) hardware<br>
changes ... we're talking from the command line ... doesn't usually<br>
show up. Sure, VMware will make a virtual CD appear when it wants to<br>
install its own driver. But what if the customer wants to do that?<br>
(especially apart from the GUI)<br>
<br>
Nominally related, there is the up-coming "VM and Linux Workshop".<br>
This year it will be at IUPUI. I believe RH is represented. I do not<br>
believe MIQ is on the agenda. (RedHatters, drop me a note off-list if<br>
there is interest.)<br>
<br>
I count five thriving architectures for Linux these days: x86, ARM,<br>
S/390 (aka "z", where I live), PPC, and SPARC. (This last one may not<br>
count as "thriving" but Oracle keeps talking about it. And I probably<br>
missed another.) Of these, about 80% support some form of<br>
virtualization. How they do virtualization varies. How they<br>
interface with hardware varies. (Emulators don't qualify. That's<br>
different.)<br>
<br>
> ... I've<br>
> been an advocate of "roll your own" management solutions such as<br>
> cfengine+SCM+kickstart etc.<br>
<br>
Mee too.<br>
Serious long term presence of any product or application requires that<br>
it integrate with the customer's operation. So there's *always* some<br>
amount of "roll your own". (And there's always back-pressure to<br>
minimize customization to ease upgrade pain.)<br>
<br>
Neal's discussion about RHN sounds like what I'm talking about.<br>
<br>
<br>
--<br>
-- R; <><<br>
_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</blockquote></div><br></div>