Open Stack

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

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.



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


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.

-- 
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/a02d3c9b/attachment.html>