<div dir="ltr">On Wed, Nov 13, 2013 at 8:02 AM, Alex Glikson <span dir="ltr"><<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><font face="sans-serif">Hi, </font>
<br>
<br><font face="sans-serif">Is there a documentation somewhere on
the scheduling flow with Ironic? </font>
<br>
<br></div><font face="sans-serif">The reason I am asking is because we
would like to get virtualized and bare-metal workloads running in the same
cloud (ideally with the ability to repurpose physical machines between
bare-metal workloads and virtualized workloads), and would like to better
understand where the gaps are (and potentially help bridging them). </font></blockquote><div><br></div><div>Hi Alex,</div><div><br></div><div>Baremetal uses an alternative scheduler, nova.scheduler.baremetal_host_manager.BaremetalHostManager, so giving that a read may be helpful. It searches the available list of baremetal nodes for one that matches the CPU, RAM, and disk capacity of the requested flavor, and compares the node's extra_specs:cpu_arch to that of the requested image, then consumes 100% of that node's available resources. Otherwise, I believe the scheduling flow is basically the same: http request to n-api, rpc passes to n-scheduler, which selects a node, and calls to n-conductor & n-cpu to do the work of spawn()ing it.</div>

<div><br></div><div>As far as the gaps in running both baremetal and virtual -- I have been told by several folks that it's possible to run both baremetal and virtual hypervisors in the same cloud by using separate regions, or separate host-aggregates, for the simple reason that these require distinct nova-scheduler processes. A single scheduler, today, can't serve both. I haven't seen any docs on how to do this, though.</div>

<div><br></div><div>As for moving a workload between them, the TripleO team has discussed this and, afaik, decided to hold off working on it for now. It would be better for them to fill in the details here -- my memory may be wrong, or things may have changed.</div>

<div><br></div><div>Cheers,</div><div>Devananda</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div>