<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Sorry for the late response.<br>
<br>
<p class="part" data-startline="1" data-endline="1"
style="box-sizing: border-box; margin-top: 0px !important;
margin-right: 0px; margin-bottom: 16px; margin-left: 0px;
position: relative; color: rgb(51, 51, 51); font-size: 16px;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
0.35px; text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width:
0px; background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;">To be on the same page,
this is how now blazar works today for the instance reservation</p>
<ol class="part" data-startline="3" data-endline="9"
style="box-sizing: border-box; margin-top: 0px; margin-bottom:
16px; padding-left: 2em; position: relative; color: rgb(51, 51,
51); font-size: 16px; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: 0.35px; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial;">
<li class="" data-startline="3" data-endline="3"
style="box-sizing: border-box;">User makes a reservation with
start-end time via Blazar API</li>
<li class="" data-startline="4" data-endline="4"
style="box-sizing: border-box; margin-top: 0.25em;">Blazar looks
up<span> </span><em style="box-sizing: border-box;">its own DB</em><span> </span>to
pick up a host to schedule the instance using<span> </span><em
style="box-sizing: border-box;">its own scheduler</em></li>
<li class="" data-startline="5" data-endline="7"
style="box-sizing: border-box; margin-top: 0.25em;">When the
reservation time starts,
<ol style="box-sizing: border-box; margin-top: 0px;
margin-bottom: 0px; padding-left: 2em;">
<li class="" data-startline="6" data-endline="6"
style="box-sizing: border-box;">Blazar gives an inventory of
that reservation resource class to the child resource
provider of the compute node resource provider Blazar has
picked up</li>
<li class="" data-startline="7" data-endline="7"
style="box-sizing: border-box; margin-top: 0.25em;">Blazar
makes a flavor which requests/consumes that reservation
resource class and expose it to the user who made that
reservation</li>
</ol>
</li>
<li class="" data-startline="8" data-endline="9"
style="box-sizing: border-box; margin-top: 0.25em;">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)</li>
</ol>
<p class="part" data-startline="10" data-endline="14"
style="box-sizing: border-box; margin-top: 0px; margin-right: 0px;
margin-bottom: 0px !important; margin-left: 0px; position:
relative; color: rgb(51, 51, 51); font-size: 16px; font-style:
normal; font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: 0.35px; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;">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.</p>
<br>
<p class="part" data-startline="10" data-endline="14"
style="box-sizing: border-box; margin-top: 0px; margin-right: 0px;
margin-bottom: 0px !important; margin-left: 0px; position:
relative; color: rgb(51, 51, 51); font-size: 16px; font-style:
normal; font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: 0.35px; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;">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 :(<br style="box-sizing:
border-box;">
</p>
<p class="part" data-startline="10" data-endline="14"
style="box-sizing: border-box; margin-top: 0px; margin-right: 0px;
margin-bottom: 0px !important; margin-left: 0px; position:
relative; color: rgb(51, 51, 51); font-size: 16px; font-style:
normal; font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: 0.35px; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;"><br>
</p>
<p class="part" data-startline="10" data-endline="14"
style="box-sizing: border-box; margin-top: 0px; margin-right: 0px;
margin-bottom: 0px !important; margin-left: 0px; position:
relative; color: rgb(51, 51, 51); font-size: 16px; font-style:
normal; font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: 0.35px; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial;">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?</p>
<br>
<br>
<div class="moz-cite-prefix">On 2019/04/22 12:07, Jay Pipes wrote:<br>
</div>
<blockquote type="cite"
cite="mid:43163072-dda5-6631-2eb5-35d5f9a9b3ea@gmail.com">My
apologies for the late response, Jason. Comments inline.
<br>
<br>
On 04/10/2019 11:24 AM, Jason Anderson wrote:
<br>
<blockquote type="cite"> On 04/10/2019 05:47 AM, Dmitry Tantsur
wrote:
<br>
> On 4/9/19 7:20 PM, Jay Pipes wrote:
<br>
>> On 04/09/2019 12:51 PM, Dmitry Tantsur wrote:
<br>
>>> From ironic perspective there is no issue, but
there is a critical
<br>
>>> question to decide: when Ironic+Placement is
used, which of them acts
<br>
>>> as the final authority? If Ironic, then we need
to teach Placement to
<br>
>>> talk to its Allocation API when allocating a
bare metal node. If
<br>
>>> Placement, then we need to support Allocation
API talking to
<br>
>>> Placement. I suspect the latter is saner, but
I'd like to hear more
<br>
>>> opinions.
<br>
>>
<br>
>> Ironic (scheduler?) would request candidates from
the placement
<br>
>> service using the GET /allocation_candidates API.
Ironic (scheduler?)
<br>
>> would then claim the resources on a provider (a
baremetal node) by
<br>
>> calling the POST /allocations API.
<br>
>
<br>
> Okay, this matches my expectation.
<br>
>
<br>
> My concern will be with Blazar and reservations. If
reservations happen
<br>
> through Placement only, how will ironic know about
them? I guess we need
<br>
> to teach Blazar to talk to Ironic, which in turn will
talk to Placement.
<br>
<br>
Hmm. So, here's the problem: placement has no concept of
time. [1]
<br>
<br>
Placement only knows about one period of time: now.
Placement doesn't
<br>
have any concept of an allocation or an inventory existing
at some
<br>
point
<br>
in the future or in the past.
<br>
<br>
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?
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
<br>
<blockquote type="cite">In my mind this would enable a more ideal
division of
<br>
responsibility:
<br>
<br>
* Placement manages the availability of resources and
maintains the
<br>
single source of truth for inventory at a given time.
<br>
</blockquote>
<br>
++
<br>
<br>
<blockquote type="cite"> * Blazar uses Placement as its default
inventory backend. Blazar's
<br>
main role now is business logic around quota and handling
<br>
allocation/deallocation when a lease starts/ends.
<br>
</blockquote>
<br>
Yes on Blazar handling the release of resources when the lease
ends.
<br>
<br>
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).
<br>
<br>
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.
<br>
<br>
Never mind the whole "we confused quotas with rate-limiting" and
"here is a type of quota that is not consistently measurable"
problems...
<br>
<br>
Anyway, my advice would be leave quotas alone if you can :)
<br>
<br>
<blockquote type="cite"> o But, Blazar could optionally use a
different inventory backend,
<br>
to allow standalone use (?)
<br>
</blockquote>
<br>
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)
<br>
<br>
<blockquote type="cite"> * Ironic uses Placement as its default
inventory backend.
<br>
o But, Ironic could optionally also manage its own
inventory, to
<br>
allow standalone use (?)
<br>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
The flexibility for close integration with arbitrary services
often comes with a high price: complexity and potential code rot.
<br>
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
Best,
<br>
-jay
<br>
<br>
<blockquote type="cite"> Therefore, Blazar must unfortunately
keep all of the temporal state
<br>
about reservations in its own data store. So, Ironic would
actually
<br>
have
<br>
to talk to Blazar to create a reservation of some amount of
resources
<br>
and Blazar will need to call Placement to manage the state
of resource
<br>
inventory and allocations over time; as reservations are
activated,
<br>
Blazar will either create or swap allocation records in
Placement to
<br>
consume the Ironic resources for a tenant that made the
reservation.
<br>
<br>
Best,
<br>
-jay
<br>
<br>
[1] this was a mistake for which I take full responsibility.
<br>
<br>
<br>
Cheers,
<br>
/Jason
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Tetsuro Nakamura <a class="moz-txt-link-rfc2396E" href="mailto:nakamura.tetsuro@lab.ntt.co.jp"><nakamura.tetsuro@lab.ntt.co.jp></a>
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 </pre>
</body>
</html>