On 15/11/13 08:46 -0600, Christopher Armstrong wrote:
On Fri, Nov 15, 2013 at 3:57 AM, Zane Bitter <zbit...@redhat.com> wrote:
On 15/11/13 02:48, Christopher Armstrong wrote:
On Thu, Nov 14, 2013 at 5:40 PM, Angus Salkeld <asalk...@redhat.com
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
and provides schemas for inputs and outputs using JSON-Schema.
document is currently at
Things we still need to figure out:
- how to scope projects/domains. put them in the URL? get them
- how webhooks are done (though this shouldn't affect the API
they're basically just opaque)
Please read and comment :)
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
- 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
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 mailing list