<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 1, 2015 at 12:07 PM, Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com" target="_blank">andrew@lascii.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/01/15 at 03:44pm, Vladyslav Drok wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi list!<br>
<br>
There is an idea of making use of hardware composition (e.g.<br>
<a href="http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html" rel="noreferrer" target="_blank">http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html</a>)<br>
to create nodes for ironic.<br>
<br>
The current proposal is:<br>
<br>
1. To create hardware-compositor service under ironic umbrella to manage<br>
this composition process. Its initial implementation will support Intel<br>
RSA, other technologies may be added in future. At the beginning, it will<br>
contain the most basic CRUD logic for composed system.<br>
<br>
2. Add logic to nova to compose a node using this new project and register<br>
it in ironic if the scheduler is not able to find any ironic node matching<br>
the flavor. An alternative (as pointed out by Devananda during yesterday's<br>
meeting) could be using it in ironic by claims API when it's implemented (<br>
<a href="https://review.openstack.org/204641" rel="noreferrer" target="_blank">https://review.openstack.org/204641</a>).<br>
</blockquote>
<br></span>
I don't think the logic should be added to Nova to create these nodes. This hardware-compositor looks like a hypervisor that can manage the subdivision of a set of resources and exposes them as a "virtual machine" in a sense. So I would expect that work to happen within the virt driver as it does for all of the others.<br>
<br>
The key thing to work out is how to expose the resources for the Nova scheduler to use. I may be simplifying the problem but it looks like the pooled system could be exposed as a compute host that can be scheduled to, and as systems are composed from the pool the consumed resources would be decremented the same as they're done today.</blockquote><div><br></div><div>I believe you've correctly described the ways such resources might be modeled and scheduled to -- there is, as I understand it, a non-arbitrarily subdivisible pool that adheres to some rules. This "compositing" moves guest isolation deeper into the hardware than virtualization does today.</div><div><br></div><div>However, this isn't a virt driver any more than nova-baremetal was a virt driver; these machines, once "composed", still need all the operational tooling of Ironic to bring a guest OS up. Also, the interfaces to "compose" these servers are hardware APIs. The service in question will communicate with a BMC or similar out-of-band hardware management device -- probably the same BMC that ironic-conductor will communicate with to boot the servers.</div><div><br></div><div>The more I think about this, the more it sounds like a special type of chassis manager -- a concept we added to Ironic in the beginning but never used -- and some changes to the nova.virt.ironic driver to call out to ?ironic?new service? and compose the servers on-the-fly, in response to a boot request, if there is available capacity.</div><div><br></div><div>Also, this is pretty far afield from where we're focusing time right now. We need to get the Ironic claims API and multiple compute host support done first.</div><div><br></div><div>-deva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. If implemented in nova, there will be no changes to ironic right now<br>
(apart from needing the driver to manage these composed nodes, which is<br>
redfish I beleive), but there are cases when it may be useful to call this<br>
service from ironic directly, e.g. to free the resources when a node is<br>
deleted.<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
Vlad<br>
</blockquote>
<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>