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

Jason Anderson jasonanderson at uchicago.edu
Wed Apr 10 15:24:19 UTC 2019


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.

Just to play devil's advocate... what about changing/adding this? What if Placement did support an inventory having different states depending on time frame requested? In my mind this would enable a more ideal division of responsibility:

  *   Placement manages the availability of resources and maintains the single source of truth for inventory at a given time.
  *   Blazar uses Placement as its default inventory backend. Blazar's main role now is business logic around quota and handling allocation/deallocation when a lease starts/ends.
     *   But, Blazar could optionally use a different inventory backend, to allow standalone use (?)
  *   Ironic uses Placement as its default inventory backend.
     *   But, Ironic could optionally also manage its own inventory, to allow standalone use (?)

To further tease out the relationships here, we should think about what makes the most sense for baremetal reservations done via Blazar. Should Blazar always go to Ironic for this, ignoring Nova entirely? Or should it go through Nova if Nova is being used? I believe Blazar still will always have to go through Nova for instance reservations at minimum.

Keep in mind that Blazar is designed to integrate with arbitrary external services; currently it has integrations with Neutron (for provisioning Floating IPs as part of a lease), and it could support any number of other resources, like bandwidth on an uplink.

Having learned more about Placement's design as a result of these threads, I'm excited about how it could make some things cleaner if it truly could handle the generic inventory management problem that advanced reservations pose.

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.

Cheers,
/Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190410/08f79ef8/attachment-0001.html>


More information about the openstack-discuss mailing list