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

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">Thanks, I understand the Nova scheduler
part. One of the gaps there is related to the blueprint we have are working
on [1]. I was wondering regarding the role of Ironic, and the exact interaction
between the user, Nova and Ironic.</font>
<br></blockquote><div><br></div><div>The interaction from the point of "nova boot" onwards will be the same -- nova maintains a list of available (host, node) resources, the scheduler picks one according to the request, dispatches the work to n-cond / n-cpu, which in turn calls down to various methods in the nova/virt/driver API. The implementation of the ironic driver is a wrapper around python-ironicclient library, which will make calls out to the ironic API service, which in turn performs the necessary work.</div>

<div><br></div><div>Where the interaction is different is around the management of physical machines; eg, enrolling them with Ironic, temporarily marking a machine as unavailable while doing maintenance on it, and other sorts of things we haven't actually written the code for yet.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">In particular, initially I thought that
Ironic is going to have its own scheduler, resolving some of the issues
and complexity within Nova (which could focus on VM management, maybe even
getting rid of hosts versus nodes, etc). </font></blockquote><div><br></div><div>I'm not sure how putting a scheduler in Ironic would solve this problem at all.</div><div><br></div><div>Conversely, I don't think there's any need for the whole (host, node) thing. Chris Behrens and I talked at the last summit about a possible rewrite to nova-conductor that would remove the need for this distinction entirely. I would love to see Nova just track node, and I think this can work for typical hypervisors (kvm, xen, ...) as well.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">But it seems that Ironic aims
to stay at the level of virt driver API.. It is a bit unclear to me what
is the desired architecture going forward - e.g., if the idea is to standardize
virt driver APIs but keep the scheduling centralized, </font></blockquote><div><br></div><div>AFAIK, the nova.virt.driver API is the standard that all the virt drivers are written to. Unless you're referring to libvirt's API, in which case, I don't understand the question. </div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">maybe we should take
the rest of virt drivers into separate projects as well, and extend Nova
to schedule beyond just compute (if it is already doing so for virt + bare-metal).
</font></blockquote><div><br></div><div>Why would Nova need to schedule anything besides compute resources? In this context, Ironic is merely providing a different type of compute resource, and Nova is still scheduling compute workloads. That this hypervisor driver has different scheduling characteristics (eg, flavor == node resource; extra_specs:cpu_arch == node arch; and so on) than other hypervisor drivers doesn't mean it's not still a compute resource.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font face="sans-serif">Alternatively, each of them could have its own scheduler (like the approach
we took when splitting out cinder, for example) - and then someone on top
(e.g., Heat) would need to do the cross-project logic. Taking different
architectural approaches in different cases confuses me a bit.</font>
<br></blockquote><div><br></div><div>Yes, well, Cinder is a different type of resource (block storage).</div><div><br></div><div><br></div><div>HTH,</div><div>-Deva</div></div></div></div>