[placement][ptg] Enabling other projects to continue with placement or get started
On 4/9/19 7:20 PM, Jay Pipes wrote:
> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
>> On 4/8/19 6:16 PM, Chris Dent wrote:
>>> Â From the etherpad 
>>> * 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.
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.
>> 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.
>>> 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
>>>  https://etherpad.openstack.org/p/placement-ptg-train