On Thu, Nov 14, 2013 at 12:52 PM, Randall Burt <randall.b...@rackspace.com>wrote:
> > On Nov 14, 2013, at 1:05 PM, Christopher Armstrong < > chris.armstr...@rackspace.com> wrote: > > On Thu, Nov 14, 2013 at 11:00 AM, Randall Burt < > randall.b...@rackspace.com> wrote: > >> >> On Nov 14, 2013, at 12:44 PM, Zane Bitter <zbit...@redhat.com> >> wrote: >> >> > On 14/11/13 18:51, Randall Burt wrote: >> >> >> >> On Nov 14, 2013, at 11:30 AM, Christopher Armstrong >> >> <chris.armstr...@rackspace.com <mailto:chris.armstr...@rackspace.com>> >> >> wrote: >> >> >> >>> On Thu, Nov 14, 2013 at 11:16 AM, Randall Burt >> >>> <randall.b...@rackspace.com <mailto:randall.b...@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/
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev