<div dir="ltr"><span id="docs-internal-guid-7979c2fb-7323-8e3c-7844-b1879f212977"><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Hi, again!</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Partick, I’ll try to explain why do we belive in some base actions like instance starting/deleting in Climate. We are thinking about the following workflow (that will be quite comfortable and user friendly, and now we have more than one customer who really want it):</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">1) User goes to the OpenStack dashboard and asks Heat to reserve several stacks.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">2) Heat goes to the Climate and creates all needed leases. Also Heat reserves all resources for these stacks.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">3) When time comes, user goes to the OpenStack cloud and here we think he wants to see already working stacks (ideal version) or (at least) already started. If no, user will have to go to the Dashboard and wake up all the stacks he or she reserved. This means several actions, that may be done for the user automatically, because it will be needed to do them no matter what is the aim for these stacks - if user reserves them, he / she needs them.</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">We understand, that there are situations when these actions may be done by some other system (like some hypothetical Jenkins). But if we speak about users, this will be useful. We also understand that this default way of behavior should be implemented in some kind of long term life cycle management system (which is not Heat), but we have no one in the OpenStack now. Because the best may to implement it is to use Convection, that is only proposal now... </span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">That’s why we think that for the behavior like “user just reserves resources and then does anything he / she wants to” physical leases are better variant, when user may reserve several nodes and use it in different ways. For the virtual reservations it will be better to start / delete them as a default way (for something unusual Heat may be used and modified).</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Do you think that this workflow is useful too and if so can you propose another implementation  variant for it?</span></p>
<br><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"></span><p dir="ltr" style="line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap">Thank you. </span></p>
<div><span style="font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;vertical-align:baseline;white-space:pre-wrap"><br></span></div></span></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Aug 12, 2013 at 1:55 PM, Patrick Petit <span dir="ltr"><<a href="mailto:patrick.petit@bull.net" target="_blank">patrick.petit@bull.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 8/9/13 3:05 PM, Nikolay Starodubtsev
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hello, Patrick!
        <br>
         <br>
        We have several reasons to think that for the virtual resources
        this possibility is interesting. If we speak about physical
        resources, user may use them in the different ways, that's why
        it is impossible to include base actions with them to the
        reservation service. But speaking about virtual reservations,
        let's imagine user wants to reserve virtual machine. He knows
        everything about it - its parameters, flavor and time to be
        leased for. Really, in this case user wants to have already
        working (or at least starting to work) reserved virtual machine
        and it would be great to include this opportunity to the
        reservation service. <br>
      </div>
    </blockquote>
    <blockquote type="cite">
      <div dir="ltr">We are thinking about base actions for the virtual
        reservations that will be supported by Climate, like boot/delete
        for instance, create/delete for volume and create/delete for the
        stacks. The same will be with volumes, IPs, etc. As for more
        complicated behaviour, it may be implemented in Heat. This will
        make reservations simpler to use for the end users.
        <br>
         <br>
        Don't you think so?
        <br>
      </div>
    </blockquote></div>
    Well yes and and no. It really depends upon what you put behind
    those lease actions. The view I am trying to sustain is separation
    of duties to keep the service simple, ubiquitous and non
    prescriptive of a certain kind of usage pattern. In other words,
    keep Climate for reservation of capacity (physical or virtual), Heat
    for orchestration, and so forth. ... Consider for example the case
    of reservation as a non technical act but rather as a business
    enabler for wholesales activities. Don't need, and probably don't
    want to start or stop any resource there. I do not deny that there
    are cases where it is desirable but then how reservations are used
    and composed together at the end of the day mainly depends on
    exogenous factors which couldn't be anticipated because they are
    driven by the business.<br>
    <br>
    And so, rather than coupling reservations with wired resource
    instantiation actions, I would rather couple them with notifications
    that everybody can subscribe to (as opposed to the Resource Manager
    only) which would let users decide what to do with the life-cycle
    events. The what to do may very well be what you advocate i.e. start
    a full stack of reserved and interwoven resources, or at the other
    end of the spectrum, do nothing at all. This approach IMO would keep
    things more open.  <br><div class="im">
    <blockquote type="cite">
      <div dir="ltr"> <br>
        P.S. Also we remember about the problem you mentioned some
        letters ago - how to guarantee that user will have already
        working and prepared host / VM / stack / etc. by the time lease
        actually starts, no just "lease begins and preparing process
        begins too". We are working on it now.<br>
      </div>
    </blockquote></div>
    Yes. I think I was explicitly referring to hosts instantiation also
    because there is no support of that in Nova API. Climate should
    support some kind of "reservation kick-in heads-up" notification
    whereby the provider and/or some automated provisioning tools could
    do the heavy lifting work of bringing physical hosts online before a
    hosts reservation lease starts. I think it doesn't have to be
    rocket-science either. It's probably sufficient to make Climate fire
    up a notification that say "Lease starting in x seconds", x being 
    an offset value against T0 that could be defined by the operator
    based on heuristics. A dedicated (e.g. IPMI) module of the Resource
    Manager for hosts reservation would subscribe as listener to those
    events.  <br><div class="im">
    <blockquote type="cite">
      <div dir="ltr">
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Thu, Aug 8, 2013 at 8:18 PM, Patrick
          Petit <span dir="ltr"><<a href="mailto:patrick.petit@bull.net" target="_blank">patrick.petit@bull.net</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000">
              <div>Hi Nikolay,<br>
                <br>
                Relying on Heat for orchestration is obviously the right
                thing to do. But there is still something in your design
                approach that I am having difficulties to comprehend
                since the beginning. Why do you keep thinking that
                orchestration and reservation should be treated
                together? That's adding unnecessary complexity IMHO. I
                just don't get it. Wouldn't it be much simpler and
                sufficient to say that there are pools of reserved
                resources you create through the reservation service.
                Those pools could be of different types i.e. host,
                instance, volume, network,.., whatever if that's really
                needed. Those pools are identified by a unique id that
                you pass along when the resource is created. That's it.
                You know, the AWS reservation service doesn't even care
                about referencing a reservation when an instance is
                created. The association between the two just happens
                behind the scene. That would work in all scenarios,
                manual, automatic, whatever... So, why do you care so
                much about this in a first place?<br>
                Thanks, <br>
                Patrick
                <div>
                  <div><br>
                    On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:<br>
                  </div>
                </div>
              </div>
              <div>
                <div>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div>Patrick, responding to your comments:</div>
                      <div><br>
                      </div>
                      <div>1) Dina mentioned "start automatically" and
                        "start manually" only as examples of how these
                        politics may look like. It doesn't seem to be a
                        correct approach to put orchestration
                        functionality (that belongs to Heat) in Climate.
                        That's why now we can implement the basics like
                        starting Heat stack, and for more complex
                        actions we may later utilize something like
                        Convection (Task-as-a-Service) project.</div>
                    </div>
                  </blockquote>
                  <blockquote type="cite">
                    <div dir="ltr">
                      <div><br>
                      </div>
                      <div>2) If we agree that Heat is the main consumer
                        of Reservation-as-a-Service, we can agree that
                        lease may be created according to one of the
                        following scenarions (but not multiple):</div>
                      <div>- a Heat stack (with requirements to stack's
                        contents) as a resource to be reserved</div>
                      <div>- some amount of physical hosts (random ones
                        or filtered based on certain characteristics). </div>
                      <div>- some amount of individual VMs OR Volumes OR
                        IPs </div>
                      <div><br>
                      </div>
                      <div>3) Heat might be the main consumer of virtual
                        reservations. If not, Heat will require
                        development efforts in order to support:</div>
                      <div>- reservation of a stack </div>
                      <div>- waking up a reserved stack</div>
                      <div>- performing all the usual orchestration work</div>
                      <div><br>
                      </div>
                      <div>We will support reservation of individual
                        instance/volume/ IP etc, but the use case with
                        "giving user already working group of connected
                        VMs, volumes, networks" seems to be the most
                        interesting one. </div>
                      <div>As for Heat autoscaling, reservation of the
                        maximum instances set in the Heat template (not
                        the minimum value) has to be implemented in
                        Heat. Some open questions remain though - like
                        updating of Heat stack when user changes the
                        template to support higher max number of running
                        instances</div>
                      <div><br>
                      </div>
                      <div>4) As a user, I would of course want to have
                        it already working, running any configured
                        hosts/stacks/etc by the time lease starts. But
                        in reality we can't predict how much time the
                        preparation process should take for every single
                        use case. So if you have an idea how this should
                        be implemented, it would be great you share your
                        opinion.</div>
                    </div>
                  </blockquote>
                </div>
              </div>
              <blockquote type="cite">
                <div dir="ltr"> </div>
                <br>
                <fieldset></fieldset>
                <br>
                <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
              </blockquote>
              <br>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <br>
    </div><span class="HOEnZb"><font color="#888888"><pre cols="72">-- 
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
<a href="http://www.bull.com" target="_blank">http://www.bull.com</a></pre>
  </font></span></div>

</blockquote></div><br></div>