On 04/10/2019 05:47 AM, Dmitry Tantsur wrote:
On 4/9/19 7:20 PM, Jay Pipes wrote:
On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
From ironic perspective there is no issue, but there is a critical question to decide: when Ironic+Placement is used, which of them acts as the final authority? If Ironic, then we need to teach Placement to talk to its Allocation API when allocating a bare metal node. If Placement, then we need to support Allocation API talking to Placement. I suspect the latter is saner, but I'd like to hear more opinions.
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.
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.
Hmm. So, here's the problem: placement has no concept of time. [1] Placement only knows about one period of time: now. Placement doesn't have any concept of an allocation or an inventory existing at some point in the future or in the past. Therefore, Blazar must unfortunately keep all of the temporal state about reservations in its own data store. So, Ironic would actually have to talk to Blazar to create a reservation of some amount of resources and Blazar will need to call Placement to manage the state of resource inventory and allocations over time; as reservations are activated, Blazar will either create or swap allocation records in Placement to consume the Ironic resources for a tenant that made the reservation. Best, -jay [1] this was a mistake for which I take full responsibility.