[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