<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@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 15/11/13 02:48, Christopher Armstrong wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld <<a href="mailto:asalkeld@redhat.com" target="_blank">asalkeld@redhat.com</a><br></div><div class="im">
<mailto:<a href="mailto:asalkeld@redhat.com" target="_blank">asalkeld@redhat.com</a>>> wrote:<br>
<br>
On 14/11/13 10:19 -0600, Christopher Armstrong wrote:<br>
<br></div>
<a href="http://docs.heatautoscale." target="_blank">http://docs.heatautoscale.</a>__<a href="http://apiary.io/" target="_blank">ap<u></u>iary.io/</a><div class="im"><br>
<<a href="http://docs.heatautoscale.apiary.io/" target="_blank">http://docs.heatautoscale.<u></u>apiary.io/</a>><br>
<br>
I've thrown together a rough sketch of the proposed API for<br>
autoscaling.<br>
It's written in API-Blueprint format (which is a simple subset<br>
of Markdown)<br>
and provides schemas for inputs and outputs using JSON-Schema.<br>
The source<br>
document is currently at<br></div>
<a href="https://github.com/radix/heat/__raw/as-api-spike/autoscaling.__apibp" target="_blank">https://github.com/radix/heat/<u></u>__raw/as-api-spike/<u></u>autoscaling.__apibp</a><div class="im"><br>
<<a href="https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp" target="_blank">https://github.com/radix/<u></u>heat/raw/as-api-spike/<u></u>autoscaling.apibp</a>><br>
<br>
<br>
Things we still need to figure out:<br>
<br>
- how to scope projects/domains. put them in the URL? get them<br>
from the<br>
token?<br>
- how webhooks are done (though this shouldn't affect the API<br>
too much;<br>
they're basically just opaque)<br>
<br>
Please read and comment :)<br>
<br>
<br>
Hi Chistopher<br>
<br>
In the group create object you have 'resources'.<br>
Can you explain what you expect in there? I thought we talked at<br>
summit about have a unit of scaling as a nested stack.<br>
<br>
The thinking here was:<br>
- this makes the new config stuff easier to scale (config get applied<br></div>
 per scaling stack)<div class="im"><br>
- you can potentially place notification resources in the scaling<br></div>
 stack (think marconi message resource - on-create it sends a<br>
 message)<div class="im"><br>
- no need for a launchconfig<br>
- you can place a LoadbalancerMember resource in the scaling stack<br></div>
 that triggers the loadbalancer to add/remove it from the lb.<div class="im"><br>
<br>
I guess what I am saying is I'd expect an api to a nested stack.<br>
<br>
<br>
Well, what I'm thinking now is that instead of "resources" (a mapping of<br>
resources), just have "resource", which can be the template definition<br>
for a single resource. This would then allow the user to specify a Stack<br>
resource if they want to provide multiple resources. How does that sound?<br>
</div></blockquote>
<br>
My thought was this (digging into the implementation here a bit):<br>
<br>
- Basically, the autoscaling code works as it does now: creates a template containing OS::Nova::Server resources (changed from AWS::EC2::Instance), with the properties obtained from the LaunchConfig, and creates a stack in Heat.<br>
- LaunchConfig can now contain any properties you like (I'm not 100% sure about this one*).<br>
- The user optionally supplies a template. If the template is supplied, it is passed to Heat and set in the environment as the provider for the OS::Nova::Server resource.<br>
<br></blockquote><div><br></div><div>I don't like the idea of binding to OS::Nova::Server specifically for autoscaling. I'd rather have the ability to scale *any* resource, including nested stacks or custom resources. It seems like jumping through hoops to support custom resources by overriding OS::Nova::Server instead of just allowing users to specify the resource that they really want directly.<br>
</div><div><br></div><div>How about we offer two "types" of configuration, one which supports arbitrary resources and one which supports OS::Nova::Server-specific launch configurations? We could just add a type="server" / type="resource" parameter which specifies which type of scaling unit to use.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This should require no substantive changes to the code since it uses existing abstractions, it makes the common case the default, and it avoids the overhead of nested stacks in the default case.<br>
<br>
cheers,<br>
Zane.<br>
<br>
* One thing the existing LaunchConfig does is steer you in the direction of not doing things that won't work - e.g. you can't specify a volume to attach to the server, because you can't attach a single boot volume to multiple servers. The way to do that correctly will be to include the volume in the provider template. So maybe we should define a set of allowed properties for the LaunchConfig, and make people hard-code anything else they want to do in the provider template, just to make it harder to do wrong things. I'm worried that would make composition in general harder though.</blockquote>
<div><br></div><div>If we offer a type="server" then the launch configuration can be restricted to things that can automatically be scaled. I think if users want more interesting scaling units they should use resources and specify both a server and a volume as heat resources.</div>
<div><br></div></div>-- <br>Christopher Armstrong<br><a href="http://radix.twistedmatrix.com/" target="_blank">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/" target="_blank">http://planet-if.com/</a><br>
<br>
</div></div>