Open Stack

On 15/11/13 02:48, Christopher Armstrong wrote:
> On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld <asalkeld at redhat.com
> <mailto:asalkeld at redhat.com>> wrote:
>
>     On 14/11/13 10:19 -0600, Christopher Armstrong wrote:
>
>         http://docs.heatautoscale.__apiary.io/
>         <http://docs.heatautoscale.apiary.io/>
>
>         I've thrown together a rough sketch of the proposed API for
>         autoscaling.
>         It's written in API-Blueprint format (which is a simple subset
>         of Markdown)
>         and provides schemas for inputs and outputs using JSON-Schema.
>         The source
>         document is currently at
>         https://github.com/radix/heat/__raw/as-api-spike/autoscaling.__apibp
>         <https://github.com/radix/heat/raw/as-api-spike/autoscaling.apibp>
>
>
>         Things we still need to figure out:
>
>         - how to scope projects/domains. put them in the URL? get them
>         from the
>         token?
>         - how webhooks are done (though this shouldn't affect the API
>         too much;
>         they're basically just opaque)
>
>         Please read and comment :)
>
>
>     Hi Chistopher
>
>     In the group create object you have 'resources'.
>     Can you explain what you expect in there? I thought we talked at
>     summit about have a unit of scaling as a nested stack.
>
>     The thinking here was:
>     - this makes the new config stuff easier to scale (config get applied
>     Â  per scaling stack)
>     - you can potentially place notification resources in the scaling
>     Â  stack (think marconi message resource - on-create it sends a
>     Â  message)
>     - no need for a launchconfig
>     - you can place a LoadbalancerMember resource in the scaling stack
>     Â  that triggers the loadbalancer to add/remove it from the lb.
>
>     I guess what I am saying is I'd expect an api to a nested stack.
>
>
> Well, what I'm thinking now is that instead of "resources" (a mapping of
> resources), just have "resource", which can be the template definition
> for a single resource. This would then allow the user to specify a Stack
> resource if they want to provide multiple resources. How does that sound?

My thought was this (digging into the implementation here a bit):

- 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.
- LaunchConfig can now contain any properties you like (I'm not 100% 
sure about this one*).
- 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.

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.

cheers,
Zane.

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