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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
