<div dir="ltr">On Thu, Nov 14, 2013 at 12:52 PM, Randall Burt <span dir="ltr"><<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<br>
<div><div><div class="h5">
<div>On Nov 14, 2013, at 1:05 PM, Christopher Armstrong <<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a>> wrote:</div>
<br>
<blockquote type="cite">
<div dir="ltr">On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt <span dir="ltr"><<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>></span> wrote:<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Nov 14, 2013, at 12:44 PM, Zane Bitter <<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>><br>
<div> wrote:<br>
<br>
> On 14/11/13 18:51, Randall Burt wrote:<br>
>><br>
>> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong<br>
>> <<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a> <mailto:<a href="mailto:chris.armstrong@rackspace.com" target="_blank">chris.armstrong@rackspace.com</a>>><br>
>> wrote:<br>
>><br>
>>> On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt<br>
>>> <<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a> <mailto:<a href="mailto:randall.burt@rackspace.com" target="_blank">randall.burt@rackspace.com</a>>> wrote:<br>
>>> Regarding web hook execution and cool down, I think the response<br>
>>> should be something like 307 if the hook is on cool down with an<br>
>>> appropriate retry-after header.<br>
><br>
> I strongly disagree with this even ignoring the security issue mentioned below. Being in the cooldown period is NOT an error, and the caller should absolutely NOT try again later - the request has been received and correctly acted upon (by doing nothing).<br>
<br>
</div>
But how do I know nothing was done? I may have very good reasons to re-scale outside of ceilometer or other mechanisms and absolutely SHOULD try again later. As it stands, I have no way of knowing that my scaling action didn't happen without examining my physical
resources. 307 is a legitimate response in these cases, but I'm certainly open to other suggestions.<br>
<div>
<div><br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I agree there should be a way to find out what happened, but in a way that requires a more strongly authenticated request. My preference would be to use an audit log system (I haven't been keeping up with the current thoughts on the design for Heat's event/log
API) that can be inspected via API.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</div></div><div>Fair enough. I'm just thinking of folks who want to set this up but use external tools/monitoring solutions for the actual eventing. Having those tools grep through event logs seems a tad cumbersome, but I do understand the desire to make these un-authenticated
secrets makes that terribly difficult.</div>
<br></div></div></blockquote><div><br></div><div>Calling it "unauthenticated" might be a bit misleading; it's authenticated by the knowledge of the URL (which implies a trust and policy to execute).<br></div>
<div><br></div></div><div><br></div>-- <br>Christopher Armstrong<br><a href="http://radix.twistedmatrix.com/" target="_blank">http://radix.twistedmatrix.com/</a><br><a href="http://planet-if.com/" target="_blank">http://planet-if.com/</a><br>
<br>
</div></div>