<html><body>
<p><tt><font size="2">Scott Moser <smoser@ubuntu.com> wrote on 05/10/2013 05:06:01 PM:<br>
<br>
> If you're going to deal with trying to know how to "install" something,<br>
> then the best way to do it is to drive a supported installer.<br>
> <br>
> Ie, kickstart or preseed or some other mechanism, where the OS is actually<br>
> the one figuring out what drivers are needed and the like.<br>
> </font></tt><br>
<br>
<tt><font size="2">Well, adding the scripted install concept is something some of us are considering offering.  ESXi and Windows installers are really just image based anyway, so supporting a .wim file with a bunch of customized stuff is nearly exactly the same as offering a .wim file with the base OS.  </font></tt><br>
<br>
<tt><font size="2">In terms of the trappings of driver injection, while I don't think Openstack can maintain the actual drivers (technical and legal problems), it wouldn't be a large stretch for it to provide a standardized framework for hardware vendors to publish driver updates to.  Openstack could then readily know how to combine the content from the software vendor with the drivers from the hardware vendor.  The infrastructure maintainers and hardware vendors they select have a better shot at knowing correct content than image publishers.</font></tt><br>
<br>
<tt><font size="2">For example, xCAT's driver architecture basically just takes whatever is in $installresources/drivers/$osver/$arch/ and recognizes how to inject them to windows, redhat, suse, and esxi.  Was thinking something like that.  The Linux ones though work in conjunction with package-oriented installers only, so if an image strategy is specifically desired for Linux on baremetal in case of missing storage driver, then a bit of a new standard would be needed, but on the same order of effort as recognizing a standardized special partition.  </font></tt><br>
<tt><font size="2"><br>
The imaging support I only see as critical in the multi-tenant baremetal case.  If the use case only covers hypervisors, then scripted install is certainly sufficient.</font></tt><br>
<br>
<tt><font size="2">Anyway, just food for thought.  The partition scheme is pretty good since it's baked on such ubiquitous stuff, but the storage controller uncertainty is just something that had repeatedly bit my team forcing us to add the driver injection historically, and I don't see much hope for change in the future.  firmware injection to memory requires a bit more os specific choices as it stands, but not much to cover the BSDs, Linux, Windows, and ESXi and you never have to worry about whether the target has driver support for your ram.</font></tt></body></html>