<tt><font size=2>Steven Hardy <shardy@redhat.com> wrote on 07/02/2014
06:02:36 AM:<br>
<br>
> On Wed, Jul 02, 2014 at 03:02:14PM +0800, Qiming Teng wrote:<br>
> > Just some random thoughts below ...<br>
> > <br>
> > On Tue, Jul 01, 2014 at 03:47:03PM -0400, Mike Spreitzer wrote:<br>
> > > ...</font></tt>
<br><tt><font size=2>> ><br>
> The resource signal interface used by ceilometer can carry whatever
data<br>
> you like, so the existing solution works fine, we don't need a new
one IMO.<br>
</font></tt>
<br><tt><font size=2>That's great, I did not know about it.  Thanks
for the details on this, I do</font></tt>
<br><tt><font size=2>think it is an improvement.  Yes, it is a slight
security downgrade --- the</font></tt>
<br><tt><font size=2>signed URL is effectively a capability, and allowing
a payload increases</font></tt>
<br><tt><font size=2>the cross section of what an attacker can do with
one stolen capability.</font></tt>
<br><tt><font size=2>But I am willing to live with it.<br>
<br>
> ...<br>
> Are you aware of the "Existence of instance" meter in ceilometer?</font></tt>
<br>
<br><tt><font size=2>I am, and was thinking it might be very directly usable.
 Has anybody tested or demonstrated this?<br>
<br>
> ...<br>
> > How about just one signal responder per ScalingGroup?  A
SG is supposed<br>
> > to be in a better position to make the judgement: do I have to
recreate<br>
> > a failed member? am I recreating it right now or wait a few seconds?<br>
> > maybe I should recreate the member on some specific AZs?<br>
> <br>
> This is what we have already - you have one ScalingPolicy (which is
a<br>
> SignalResponder), and the ScalingPolicy is the place where you make
the<br>
> decision about what to do with the data provided from the alarm.</font></tt>
<br>
<br><tt><font size=2>I think the existing ScalingPolicy is about a different
issue.  ScalingPolicy is mis-named; it is really only a ScalingAction,
and it is about how to adjust the desired size.  It does not address
the key missing piece here, which is how the scaling group updates its
accounting of the number of members it has.  That accounting is done
simply by counting members.  So if a member becomes dysfunctional
but remains extant, the scaling group logic continues to count it.</font></tt>
<br>
<br><tt><font size=2>Hmm, can a scaling group today properly cope with
member deletion if prodded to do a ScalingPolicy(Action) that is 'add 1
member'?  (I had considered 'add 0 members' but that fails to produce
a change in an important case --- when the size is now below minimum (fun
fact about the code!). )</font></tt>
<br><tt><font size=2><br>
> ...<br>
> > I am not in favor of the per-member webhook design.  But
I vote for an<br>
> > additional *implicit* parameter to a nested stack of any groups.
 It<br>
> > could be an index or a name.<br>
> <br>
> I agree, we just need appropriate metadata in ceilometer, which can
then be<br>
> passed back to heat via the resource signal when the alarm happens.<br>
</font></tt>
<br><tt><font size=2>We need to get the relevant meter samples in Ceilometer
tagged with something that is unique to the [scaling group, member] and
referencable in the template source.  For the case of a scaling group
whose member type is nested stack, you could invent a way to implicitly
pass such tagging down through all the intervening abstractions.  I
was supposing the preferred solution would be for the template author to
explicitly do this.</font></tt>
<br><tt><font size=2><br>
> ...<br>
</font></tt>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>