Open Stack

On 4/12/19 7:02 PM, Pierre Riteau wrote:
> On Wed, 10 Apr 2019 at 12:16, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>>
>> On 4/10/19 12:14 PM, Jay Pipes wrote:
>>> 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.
>>
>> I imagined it a bit differently. I assumed that
>> 1. a user (operator?) talks to Blazar to create a bare metal node reservation.
>> 1.1. some kind of quota is checked? does Blazar have any notion of quota?
>> 2. Blazar talks to Ironic to create an allocation (yes, we also call it
>> allocation, feel free to blame me)
>> 3. Ironic gets a reservation from Placement and updates its internal records
>> 4. Ironic returns an allocation to Blazar
>> 5. Blazar returns a reservation to a user
>>
>> And when a reservation in Blazar expires or is returned:
>> 6. Blazar talks to Ironic to undeploy the node
>> 6.1. Ironic deletes its allocation automatically
>> 6.2. And thus notifies Placement to remove its allocation
>>
>> Am I missing something?
> 
> If we follow the current model used with Nova and now also with
> Neutron, Blazar would be directly aware of all Ironic nodes (we store
> a copy of the essential resource information in the Blazar database).
> It would use it to make its own resource allocation decisions for
> future reservations. On reservation start, it could call Ironic to
> create an allocation on the node with `candidate_nodes` and provide it
> to the reservation's owner for deployment.
> 
> However, is there a way to prevent anyone but the reservation's owner
> from using the corresponding Ironic allocation? From looking at the
> API doc, I couldn't really see any enforcement of Ironic allocations
> being done.

There is no enforcement currently, it's cooperative. We're going to discuss 
Ironic multi-tenancy at the Forum 
https://www.openstack.org/summit/denver-2019/summit-schedule/events/23668/ironic-multi-tenancy-and-hardware-leasing 
and later at the PTG, and this is probably going to be they key question.

One way we could solve it is to create a new Deployment API in ironic (we have 
been thinking about it for long time), and create more fine-grained policies for 
who can use it and how. For example, disallow changing nodes, allow deployment 
API, but only for previously allocated nodes.

This will need some notion of an owner for an allocation or to dynamically 
change the owner field of a node.

> 
> I am not sure how placement fits into this. If Ironic starts using
> placement for its allocation API, as it is mentioned in
> https://storyboard.openstack.org/#!/story/2004341, we would figure out
> a way for Blazar to put a hold on reservable nodes, so that users
> allocating directly with Ironic could only request from a
> non-reservable pool of nodes. Blazar would create Ironic allocation on
> behalf of users as described above. The question of allocation
> enforcement is also critical in this scenario.

We probably need to work on a story of integrating the "owner" field with the 
allocation API. This is something I'm hoping to define and implement in Train 
with your input.

> 
> PS: Blazar doesn't handle any quota yet. It's a major flaw so we'll
> need to tackle it soon. I am hoping we'll be able to leverage unified
> limits for this.
>