[openstack-dev] [Heat] rough draft of Heat autoscaling API
asalkeld at redhat.com
Sat Nov 16 10:15:15 UTC 2013
On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
>On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter <zbitter at redhat.com> wrote:
>> 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:
>>> I've thrown together a rough sketch of the proposed API for
>>> 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
>>> Things we still need to figure out:
>>> - how to scope projects/domains. put them in the URL? get them
>>> from the
>>> - 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
>> - 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.
>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
big +1 here, autoscaling should not even know what it is scaling, just
some resource. solum might want to scale all sorts of non-server
resources (and other users).
>support custom resources by overriding OS::Nova::Server instead of just
>allowing users to specify the resource that they really want directly.
>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.
How about just one "nested-stack".
Keep it simple.
>> 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.
>> * 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
>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.
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev