Sounds good to me.
On Mon, Oct 13, 2014 at 11:51 AM, Bill Farner wrote:
> We had a discussion about this in our weekly community meeting in IRC
> today, and after some debate there was unanimous agreement to avoid all
> time control but to use the presence of the snooze file only. Below is the
We had a discussion about this in our weekly community meeting in IRC
today, and after some debate there was unanimous agreement to avoid all
time control but to use the presence of the snooze file only. Below is the
excerpt from the discussion. If you disagree, feel free to continue the
discussi
Ignore my first response, i think gmail drafts are out to get me.
-=Bill
On Fri, Oct 10, 2014 at 3:30 PM, Bill Farner wrote:
> I'm cool with #2, specifically if we do not attempt to parse the file and
> use that to determine the auto-expire time.
>
>
> -=Bill
>
> On Fri, Oct 10, 2014 at 2:48 PM
I'm cool with #2, specifically if we do not attempt to parse the file and
use that to determine the auto-expire time.
-=Bill
On Fri, Oct 10, 2014 at 2:48 PM, Joshua Cohen
wrote:
> I'm in camp #2, I don't feel that it adds a significant amount of
> complexity to the health check logic, and it p
I'm generally in #1, but could land somewhere in between. I think the idea
of using mtime came up, which i like more than parsing the snooze file and
giving full control. I'd be fine with expiring this file at mtime +
SNOOZE_TIMEOUT (constant). This fails closed, is relatively simple to
implemen
I'm in camp #2, I don't feel that it adds a significant amount of
complexity to the health check logic, and it provides a substantial
safeguard against users accidentally shooting themselves in the foot by
accidentally leaving a health check snoozed.
On Fri, Oct 10, 2014 at 2:32 PM, Maxim Khutorne
+1 #2. We don't surface disabling health checks anywhere to the user. I
think the system should err on the side of caution and get to the state
that it is advertising on the UI.
On Fri, Oct 10, 2014 at 2:32 PM, Maxim Khutornenko wrote:
> +1 to the #1. Disabling health checks is like signing a wa
+1 to the #1. Disabling health checks is like signing a waiver where
all health check guarantees are off.
On Fri, Oct 10, 2014 at 2:23 PM, David Pan wrote:
> Hi Aurora,
>
> I am currently working on a feature that allows for health checks to be
> disabled temporarily for a running instance of a j
Hi Aurora,
I am currently working on a feature that allows for health checks to be
disabled temporarily for a running instance of a job. The code review can
be found at https://reviews.apache.org/r/26383/. The idea is that the
presence of a special "snooze file" in the task's sandbox will trigge
