<div dir="ltr">> Message: 3<br>> Date: Mon, 31 Mar 2014 05:16:38 -0400 (EDT)<br>
> From: Barak Azulay <<a href="mailto:bazulay@redhat.com">bazulay@redhat.com</a>><br>
> To: Fabian Deutsch <<a href="mailto:fabiand@redhat.com">fabiand@redhat.com</a>><br>
> Cc: <a href="mailto:arch@ovirt.org">arch@ovirt.org</a>, Douglas Landgraf <<a href="mailto:dlandgra@redhat.com">dlandgra@redhat.com</a>>, node-devel <<a href="mailto:node-devel@ovirt.org">node-devel@ovirt.org</a>><br>
> Subject: Re: [node-devel] Versioning of oVirt Node<br>
<br>> Any idea why ?<br>
<br>> The only thing I can think off is that we are probably doing something wrong.<br>
<div class="gmail_extra"><br></div><div class="gmail_extra">For my part, because knowing what it's based on allows me to pick based upon feature sets and known compatibility with addons. I know that a Fedora-based image will support nested virt if I want to install that VDSM hook. And CentOS will support Dell's monitoring tools.<br>
<br>Building from scratch with libvirt and busybox, even if hyperbolic, would make adding plugins, vendor tools, or anything else exceptionally problematic unless we were to reinvent RPM or an oVirt-specific VIB. Debian stable presents some of the same problems.<br>
<br>We may be able to get away with an EL7-based build only until it diverges too far from Fedora, at least, but I can't help but see this as a temporary solution.<br></div><div class="gmail_extra">-- <br>while (!asleep) { sheep++; }
</div></div>