Open Stack

Sorry for the late response.

To be on the same page, this is how now blazar works today for the 
instance reservation

 1. User makes a reservation with start-end time via Blazar API
 2. Blazar looks up/its own DB/to pick up a host to schedule the
    instance using/its own scheduler/
 3. When the reservation time starts,
     1. Blazar gives an inventory of that reservation resource class to
        the child resource provider of the compute node resource
        provider Blazar has picked up
     2. Blazar makes a flavor which requests/consumes that reservation
        resource class and expose it to the user who made that reservation
 4. The user boots an instance with that flavor, and placement will
    schedule that instance to the compute node blazar has picked since
    the compute node is only a resource provider which has that
    reservation class inventory (in its child resource provider)

Since I’m not familiar with Ironic I’m not sure what will be the pain 
point (technical blocker) to use the same mechanism for Ironic driver.


The pain point for Blazar itself so far is the second part of the above 
sequence, that said Blazer’s mini scheduler doesn’t consider traits or 
even the overcommitting ratio in placement :(


Jay’s idea, I think, enables Blazar to offload to and rely on Placement 
only that second sequence task, solving those pain points. That sounds 
attractive to me, but on the other hand, I also don’t want every user to 
go through the new “temporal” searching path since it is useless for 
I-don’t-care-about-time users, So the point, IMO, is if we can (or 
really should?) skip the temporal stuff if not needed and if we can 
centralize the code for time in implementation since developers don’t 
want to always be aware of dealing time?



On 2019/04/22 12:07, Jay Pipes wrote:
> My apologies for the late response, Jason. Comments inline.
>
> On 04/10/2019 11:24 AM, Jason Anderson 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.
>>
>> 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?
>
> After 3+ years with the placement modeling, I've come to realize it 
> was a fundamental mistake to not include a temporal aspect to both the 
> inventories and allocations table schemas.
>
> While I would *not* support a schema that had different "states" for 
> an inventory depending on the time frame requested, I *do* think that 
> adding a claim_time and release_time column to the allocations table 
> and a start_time and end_time column to the inventories table would 
> allow Placement to fulfill a simple reservation system using the same 
> transactional logic it currently uses.
>
>> 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.
>
> Yes on Blazar handling the release of resources when the lease ends.
>
> No on Blazar handling the acquisition of resources when the lease 
> starts (that would fundamentally be accomplished by Placement if 
> Placement had a temporal dimension to its allocations and inventories 
> table schemas).
>
> No on Blazar handling quota. Quota is a giant pain in the behind, 
> frankly. Trust me, you want no part of it ;) No matter how many 
> "dimensions" of quota slicing and dicing are made available, operators 
> will always want to add yet another dimension. If it's not quota 
> "classes", then it's different quotas per region, then different 
> quotas per AZ, then different quotas per aggregate, and on and on.
>
> Never mind the whole "we confused quotas with rate-limiting" and "here 
> is a type of quota that is not consistently measurable" problems...
>
> Anyway, my advice would be leave quotas alone if you can :)
>
>>       o But, Blazar could optionally use a different inventory backend,
>>         to allow standalone use (?)
>
> Not sure why you'd want to do this. But, as Dima remarked in another 
> sub-thread of this conversation, the question about "which things 
> should a standalone service depend on" is a religious debate. (and a 
> debate I no longer have the energy to participate in)
>
>>   * Ironic uses Placement as its default inventory backend.
>>       o 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.
>
> Certainly Blazar will have to go through Nova *in its current 
> implementation*, since Blazar currently relies on host aggregates and 
> special aggregate and flavor metadata to "reserve" compute nodes.
>
>> 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.
>
> The flexibility for close integration with arbitrary services often 
> comes with a high price: complexity and potential code rot.
>
>> 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.
>
> If you will be in Denver, I'm happy to outline some ideas I had that 
> would pave a way for adding a temporal dimension to Placement's 
> database schema. I won't be able to implement these ideas, but I'm 
> happy to share them with you if you're interested.
>
> Best,
> -jay
>
>>     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
>
>

-- 
Tetsuro Nakamura <nakamura.tetsuro at lab.ntt.co.jp>
NTT Network Service Systems Laboratories
TEL:0422 59 6914(National)/+81 422 59 6914(International)
3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190424/14afb91b/attachment-0001.html>