<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 16, 2016 at 6:27 PM, Sean Myers <span dir="ltr"><<a href="mailto:sean.myers@redhat.com" target="_blank">sean.myers@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11/16/2016 05:28 PM, Michael Hrivnak wrote:<br>
> Options:<br>
> - We could set the policy to SET_NULL. When the worker entry gets deleted,<br>
> the task would simply lose its record of which worker it ran on.<br>
<br>
</span>+1 to this.<br>
<br>
Since the worker no longer exists in that scenario, I don't think we lose any<br>
data there, right? A reference to a nonexistent worker is as good as NULL. Do<br>
we need to add a task scrubber to find tasks with NULL workers and make sure<br>
they get reassigned? We could also use SET() here, and pass it a callable that<br>
sets it to an extant worker pk, but at the moment I think I prefer SET_NULL.<br></blockquote><div><br></div><div>Keeping the worker and host names could still be valuable for later analysis, such as correlating tasks with logs. We've heard from users that they want an easier time figuring out which process ran a task, when digging through log data later. Granted, we could do that by just adding better log statements too, but this is an opportunity to help point in the right direction.</div><div><br></div><div>Concocting a scenario, consider if a user saw repeated failures of a particular kind, such as chronic download errors. Seeing that all of the tasks with such errors ran on the same machine in their cluster could be a huge help in identifying bad hardware, a local misconfiguration, etc.</div><div><br></div><div>I don't think any of this is an especially strong use case, but is worth considering. It does strike me as unexpected to actively take away the worker name just because the worker stopped. I think users could find that surprising.</div><div><br></div><div>But I can live with any of these options as long as we prevent the cascade delete.</div><div><br></div><div>Michael</div></div></div></div>