<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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<br>
      On 8/7/13 3:35 PM, Nikolay Starodubtsev wrote:<br>
    </div>
    <blockquote
cite="mid:CAAa8YgDe40EDuKCCt=HhmnOo74Qw53DHeEq7ojvTJbR1cUJg=g@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <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
cite="mid:CAAa8YgDe40EDuKCCt=HhmnOo74Qw53DHeEq7ojvTJbR1cUJg=g@mail.gmail.com"
      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>
    <blockquote
cite="mid:CAAa8YgDe40EDuKCCt=HhmnOo74Qw53DHeEq7ojvTJbR1cUJg=g@mail.gmail.com"
      type="cite">
      <div dir="ltr">
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>