Open Stack

On Tue, Dec 1, 2015 at 12:07 PM, Andrew Laski <andrew at lascii.com> wrote:

> On 12/01/15 at 03:44pm, Vladyslav Drok wrote:
>
>> Hi list!
>>
>> There is an idea of making use of hardware composition (e.g.
>>
>> http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html
>> )
>> to create nodes for ironic.
>>
>> The current proposal is:
>>
>> 1. To create hardware-compositor service under ironic umbrella to manage
>> this composition process. Its initial implementation will support Intel
>> RSA, other technologies may be added in future. At the beginning, it will
>> contain the most basic CRUD logic for composed system.
>>
>> 2. Add logic to nova to compose a node using this new project and register
>> it in ironic if the scheduler is not able to find any ironic node matching
>> the flavor. An alternative (as pointed out by Devananda during yesterday's
>> meeting) could be using it in ironic by claims API when it's implemented (
>> https://review.openstack.org/204641).
>>
>
> 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.
>
> 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.


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.

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.

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.

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.

-deva



>
>
>
>> 3. If implemented in nova, there will be no changes to ironic right now
>> (apart from needing the driver to manage these composed nodes, which is
>> redfish I beleive), but there are cases when it may be useful to call this
>> service from ironic directly, e.g. to free the resources when a node is
>> deleted.
>>
>> Thoughts?
>>
>> Thanks,
>> Vlad
>>
>
> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151201/822bb132/attachment.html>