Open Stack

On 4/10/19 12:11 PM, Chris Dent wrote:
> 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.

We would rather have ironic aware that some nodes are reserved for internal 
bookkeeping.

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