[placement][ptg] Enabling other projects to continue with placement or get started

Jay Pipes jaypipes at gmail.com
Tue Apr 9 17:20:06 UTC 2019


On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
> On 4/8/19 6:16 PM, Chris Dent wrote:
>>
>>  From the etherpad [1]
>>
>> * blazar
>> * cinder
>> * cyborg
>> * ironic
>> * neutron
>>
>> Who else?
>>
>> This is a bit of a catch-many topic. Despite being birthed in Nova,
>> Placement is designed to be useful to lots of different services.
>>
>> There's already some time defined at the PTG to talk about the
>> interaction of Ironic, Blazar, and Placement.
>>
>> What are the issues with that?
> 
>  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.

> In both cases we'll need something that syncs nodes from Ironic to 
> Placement when there is no Compute to do it.

Yep, this is absolutely correct. My advice: don't bother copying any 
code from the nova-compute resource tracker. It's horrible.

Best,
-jay

>> What are the issues other services are experiencing with Placement?
>> Preventing people from using Placement?
>>
>> What services are using Placement and the team doesn't know about
>> it?
>>
>>
>> [1] https://etherpad.openstack.org/p/placement-ptg-train
>>
> 
> 



More information about the openstack-discuss mailing list