<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">On 11/18/2013 01:03 PM, Christopher
      Armstrong wrote:<br>
    </div>
    <blockquote
cite="mid:CAPkRfUTj-Cj0eCR_iw02USinfwpCdXo2Uc1bcdZT02ZWOyEagw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Sun, Nov 17, 2013 at 2:57 PM,
            Steve Baker <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:sbaker@redhat.com" target="_blank">sbaker@redhat.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="im">On 11/15/2013 05:19 AM, Christopher
                Armstrong wrote:<br>
              </div>
              <div class="im">> <a moz-do-not-send="true"
                  href="http://docs.heatautoscale.apiary.io/"
                  target="_blank">http://docs.heatautoscale.apiary.io/</a><br>
                ><br>
                > I've thrown together a rough sketch of the proposed
                API for<br>
                > autoscaling. It's written in API-Blueprint format
                (which is a simple<br>
                > subset of Markdown) and provides schemas for inputs
                and outputs using<br>
                > JSON-Schema. The source document is currently<br>
                > at <a moz-do-not-send="true"
                  href="https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp"
                  target="_blank">https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp</a><br>
                ><br>
              </div>
              Apologies if I'm about to re-litigate an old argument,
              but...<br>
              <br>
              At summit we discussed creating a new endpoint (and new
              pythonclient)<br>
              for autoscaling. Instead I think the autoscaling API could
              just be added<br>
              to the existing heat-api endpoint.<br>
              <br>
              Arguments for just making auto scaling part of heat api
              include:<br>
              * Significantly less development, packaging and deployment
              configuration<br>
              of not creating a heat-autoscaling-api and
              python-autoscalingclient<br>
              * Autoscaling is orchestration (for some definition of
              orchestration) so<br>
              belongs in the orchestration service endpoint<br>
              * The autoscaling API includes heat template snippets, so
              a heat service<br>
              is a required dependency for deployers anyway<br>
              * End-users are still free to use the autoscaling portion
              of the heat<br>
              API without necessarily being aware of (or directly using)
              heat<br>
              templates and stacks<br>
              * It seems acceptable for single endpoints to manage many
              resources (eg,<br>
              the increasingly disparate list of resources available via
              the neutron API)<br>
              <br>
              Arguments for making a new auto scaling api include:<br>
              * Autoscaling is not orchestration (for some narrower
              definition of<br>
              orchestration)<br>
              * Autoscaling implementation will be handled by something
              other than<br>
              heat engine (I have assumed the opposite)<br>
              (no doubt this list will be added to in this thread)<br>
              <br>
              What do you think?<br>
              <div class="HOEnZb">
                <div class="h5"><br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I would be fine with this. Putting the API at the same
              endpoint as Heat's API can be done whether we decide to
              document the API as a separate thing or not. Would you
              prefer to see it as literally just more features added to
              the Heat API, or an "autoscaling API" that just happens to
              live at the same endpoint?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I have no preference here. It is currently mostly inside /groups/
    anyway, this seems like a reasonable base path.<br>
  </body>
</html>