Open Stack

On Thu, Nov 14, 2013 at 12:52 PM, Randall Burt
<randall.burt at rackspace.com>wrote:

>
>  On Nov 14, 2013, at 1:05 PM, Christopher Armstrong <
> chris.armstrong at rackspace.com> wrote:
>
>  On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt <
> randall.burt at rackspace.com> wrote:
>
>>
>> On Nov 14, 2013, at 12:44 PM, Zane Bitter <zbitter at redhat.com>
>>  wrote:
>>
>> > On 14/11/13 18:51, Randall Burt wrote:
>> >>
>> >> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong
>> >> <chris.armstrong at rackspace.com <mailto:chris.armstrong at rackspace.com>>
>> >>  wrote:
>> >>
>> >>> On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt
>> >>> <randall.burt at rackspace.com <mailto:randall.burt at rackspace.com>>
>> wrote:
>> >>>    Regarding web hook execution and cool down, I think the response
>> >>>    should be something like 307 if the hook is on cool down with an
>> >>>    appropriate retry-after header.
>> >
>> > 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).
>>
>>  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.
>>
>>
>  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.
>
>
>  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.
>
>
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).


-- 
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131114/bfd3e661/attachment.html>