On Nov 14, 2013, at 1:05 PM, Christopher Armstrong <[email protected]<mailto:[email protected]>> wrote:
On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt <[email protected]<mailto:[email protected]>> wrote: On Nov 14, 2013, at 12:44 PM, Zane Bitter <[email protected]<mailto:[email protected]>> wrote: > On 14/11/13 18:51, Randall Burt wrote: >> >> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong >> <[email protected]<mailto:[email protected]> >> <mailto:[email protected]<mailto:[email protected]>>> >> wrote: >> >>> On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt >>> <[email protected]<mailto:[email protected]> >>> <mailto:[email protected]<mailto:[email protected]>>> >>> 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. -- IRC: radix Christopher Armstrong Rackspace _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
