Open Stack

On Wed, 10 Apr 2019, Dmitry Tantsur wrote:
> On 4/9/19 7:20 PM, Jay Pipes wrote:
>> Ironic (scheduler?) would request candidates from the placement service 
>> using the GET /allocation_candidates API. Ironic (scheduler?) would then 
>> claim the resources on a provider (a baremetal node) by calling the POST 
>> /allocations API.
>
> Okay, this matches my expectation.

One of the reasons I wrote my etcd-compute [1] compute thing was to
demo how simple the inventory writing, candidate selection
(scheduling), allocation writing can be if a) assume that placement
is where the truth lives, b) represent everything that matters in
the scheduling decisions in placement, c) only care about stuff that
really matters (so (b) can be straightforward).

It does what Jay describes in his paragraph above and that is
pretty much the basic model for using placement.

(Except, to be pedantic, for a single consumer the PUT
/allocations/{consumer_uuid} API would be the normal one for
"claiming". POST is for manipulating multiple allocations in one
(atomic) request.)j

> My concern will be with Blazar and reservations. If reservations happen 
> through Placement only, how will ironic know about them? I guess we need to 
> teach Blazar to talk to Ironic, which in turn will talk to Placement.

One option would be that Blazar talks to placement, making some
stuff resources unavailable. Ironic doesn't specifically need to
know that they are unavailable, it is would rather be the case they
are not present in scheduling results.

[1] https://github.com/cdent/etcd-compute

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent