Open Stack

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

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.

-1

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

>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev