<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>