[openstack-dev] [Heat] rough draft of Heat autoscaling API
zbitter at redhat.com
Mon Nov 18 09:24:02 UTC 2013
On 16/11/13 11:11, Angus Salkeld wrote:
> On 15/11/13 16:32 +0100, Zane Bitter wrote:
>> On 14/11/13 19:53, Christopher Armstrong wrote:
>>> I'm a little unclear as to what point you're making here. Right now, the
>>> "launch configuration" is specified in the scaling group by the
>>> "resources" property of the request json body. It's not a full template,
>>> but just a "snippet" of a set of resources you want scaled.
>> Right, and this has a couple of effects, particularly for Heat:
>> 1) You can't share a single launch config between scaling groups -
>> this hurts composability of templates.
>> 2) The AWS::EC2::Launch config wouldn't correspond to a real API, so
>> we would have to continue to implement it using the current hack.
> IMHO we should not let the design be altered by aws resources.
> - let lauchconfing be ugly.
So, if our design was clearly better I probably would agree with you.
But having launchconfig as a thing separate from a scaling group means:
* You can share one launch config between multiple scaling groups - it's
* You can delete a scaling group and then recreate it again without
respecifying all of the launchconfig parameters (which are the finicky
* The CLI interface can be much simpler, since you wouldn't have to
supply all the configuration for the scaling group and the server
properties at the same time.
So I would would want this whether or not it enabled us to eliminate a
bunch of magic/hackery/technical debt from our AWS-compatible resource
plugins. It does though, which is even more reason to do it.
> - make the primary interface of a scaling unit be a nested stack (with
> our new config resources etc..)
So, I don't think we disagree in concept here, only about the
Surely, though, we don't want to require the user to provide a Heat
template for every operation? One of the goals of a separate autoscaling
API is that you shouldn't need to write Heat templates to use
autoscaling in the simplest case (though, of course, it's completely
appropriate to require writing templates expose more powerful features).
That could still be achieved by having a default template that just
contains an OS::Nova::Server, but now we're back to just disagreeing
about implementation details.
More information about the OpenStack-dev