Open Stack

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 
more composable.
* You can delete a scaling group and then recreate it again without 
respecifying all of the launchconfig parameters (which are the finicky 
part).
* 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 
implementation...

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.

cheers,
Zane.