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