As I got a nod from Vish on IRC about this feature, I've proposed a change to implement it, along with a new test. I'll update the corresponding baremetal patch once this merges.<div><br></div><div><a href="https://review.openstack.org/#/c/16122/">https://review.openstack.org/#/c/16122/</a><br>
</div><div><br></div><div>-Deva</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 14, 2012 at 10:08 AM, David Kang <span dir="ltr"><<a href="mailto:dkang@isi.edu" target="_blank">dkang@isi.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
+1<br>
<br>
David<br>
<div><div class="h5"><br>
----- Original Message -----<br>
> Hi all,<br>
><br>
><br>
> Is there a policy regarding use of _extra_specs for supplying the virt<br>
> layer with information that it requires to start an instance? I ask<br>
> because right now, _extra_specs is not getting passed with the<br>
> $instance object to driver.spawn(), but IMHO the baremetal driver<br>
> should be utilizing this. If it's OK to do this, I will propose that<br>
> patch.<br>
><br>
><br>
><br>
><br>
> A little background -- baremetal deployment process is a two (or more)<br>
> step process.<br>
> 1. PXE boot the hw into a "deploy" kernel+ramdisk. This is used to<br>
> write the user-specified image onto the local disks.<br>
> 2. hw restarts, and PXE boots into the kernel+ramdisk which belong to<br>
> the user-specified image.<br>
><br>
><br>
> (*) there could be other steps chained into this, such as hw<br>
> discovery, burn-in, etc, but that's ancillary to the question here.<br>
><br>
><br>
> For baremetal, a flavor represents a specific set of hardware<br>
> capabilities (how much physical ram, cpu, disk, etc). The deploy k+r<br>
> used in step 1 is likely to be hardware specific, eg. dependent upon<br>
> CPU arch, any specific network drivers that need to be loaded, and so<br>
> on. Thus, it seems logical to specify it on the flavor extra_specs as<br>
> opposed to the current approaches, both of which I see problems with:<br>
> a) nova config option, b) image metadata.<br>
><br>
><br>
><br>
> Regards,<br>
> Devananda<br>
</div></div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>