<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/19/2013 04:35 AM, Mike Spreitzer
wrote:<br>
</div>
<blockquote
cite="mid:OF63DC6E2E.8B653827-ON85257BEB.00239649-85257BEB.003FAB5E@us.ibm.com"
type="cite"><font face="sans-serif" size="2">I'd like to try to
summarize this discussion,
if nothing else than to see whether I have correctly understood
it. There
is a lot of consensus, but I haven't heard from Adrian Otto
since he wrote
some objections. I'll focus on trying to describe the
consensus;
Adrian's concerns are already collected in a single message. Or
maybe
this is already written in some one place?</font>
<br>
<br>
<font face="sans-serif" size="2">The consensus is that there
should be
an autoscaling (AS) service that is accessible via its own API.
This
autoscaling service can scale anything describable by a snippet
of Heat
template (it's not clear to me exactly what sort of syntax this
is; is
it written up anywhere?). The autoscaling service is stimulated
into
action by a webhook call. The user has the freedom to arrange
calls
on that webhook in any way she wants. It is anticipated that a
common
case will be alarms raised by Ceilometer. For more specialized
or
complicated logic, the user is free to wire up anything she
wants to call
the webhook.</font>
<br>
<br>
<font face="sans-serif" size="2">An instance of the autoscaling
service
maintains an integer variable, which is the current number of
copies of
the thing being autoscaled. Does the webhook call provide a new
number,
or +1/-1 signal, or ...?</font>
<br>
<br>
<font face="sans-serif" size="2">There was some discussion of a
way to
indicate which individuals to remove, in the case of decreasing
the multiplier.
I suppose that would be an option in the webhook, and one that
will
not be exercised by Ceilometer alarms.</font>
<br>
<br>
<font face="sans-serif" size="2">(It seems to me that there is not
much
"auto" in this autoscaling service --- it is really a scaling
service driven by an external controller. This is not a
criticism,
I think this is a good factoring --- but maybe not the best
naming.)</font>
<br>
<br>
<font face="sans-serif" size="2">The autoscaling service does its
job
by multiplying the heat template snippet (the thing to be
autoscaled) by
the current number of copies and passing this derived template
to Heat
to "make it so". As the desired number of copies changes,
the AS service changes the derived template that it hands to
Heat. Most
commentators argue that the consistency and non-redundancy of
making the
AS service use Heat outweigh the extra path-length compared to a
more direct
solution.</font>
<br>
<br>
<font face="sans-serif" size="2">Heat will have a resource type,
analogous
to AWS::AutoScaling::AutoScalingGroup, through which the
template author
can request usage of the AS service.</font>
<br>
<br>
<font face="sans-serif" size="2">OpenStack in general, and Heat in
particular,
need to be much better at traceability and debuggability; the AS
service
should be good at these too.</font>
<br>
<br>
<font face="sans-serif" size="2">Have I got this right?</font>
<br>
<br>
</blockquote>
<br>
Mike,<br>
<br>
The key contention to a separate API is that Heat already provides
all of this today. It is unclear to me how separating a specially
designed autoscaling service from Heat would be of big benefit
because we still need the launch configuration and properties of the
autoscaling group to be specified. A separate service may specify
this in REST API calls, whereas heat specifies it in a template, but
really, this isn't much of a difference from a user's view. The
user still has to pass all of the same data set in some way. Then
there is the issue of duplicated code for at-least handling the
creation and removal of the server instances themselves, and the
bootstrapping that occurs in the process.<br>
<br>
Your thread suggests we remove the "auto" from the "scaling" - these
two concepts seem tightly integrated to me, and my personal opinion
is doing so is just a way to work around the need to pass all of the
necessary autoscaling parameters in API calls. IMO there is no real
benefit in a simple scaling service that is directed by a third
party software component (in the proposed case Heat, activated on
Ceilometer Alarms). It just feels like it doesn't "do enough" to
warrant an entire OpenStack program. There is significant overhead
in each OS program added and I don't see the gain for the pain.<br>
<br>
I think these are the main points of contention at this point, with
no clear consensus.<br>
<br>
An alternate point in favor of a separate autoscaling component not
mentioned in your post is that an API produces a more composable[1]
system which brings many advantages.<br>
<br>
Regards<br>
-steve<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<br>
[1] <a href="http://en.wikipedia.org/wiki/Composability">http://en.wikipedia.org/wiki/Composability</a><br>
<br>
<blockquote
cite="mid:OF63DC6E2E.8B653827-ON85257BEB.00239649-85257BEB.003FAB5E@us.ibm.com"
type="cite"><font face="sans-serif" size="2">Thanks,</font>
<br>
<font face="sans-serif" size="2">Mike</font>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>