[Pulp-dev] pulp3: task - worker relationship

Michael Hrivnak mhrivnak at redhat.com
Thu Nov 17 14:36:04 UTC 2016

On Wed, Nov 16, 2016 at 6:27 PM, Sean Myers <sean.myers at redhat.com> wrote:

> On 11/16/2016 05:28 PM, Michael Hrivnak wrote:
> > Options:
> > - We could set the policy to SET_NULL. When the worker entry gets
> deleted,
> > the task would simply lose its record of which worker it ran on.
> +1 to this.
> Since the worker no longer exists in that scenario, I don't think we lose
> any
> data there, right? A reference to a nonexistent worker is as good as NULL.
> Do
> we need to add a task scrubber to find tasks with NULL workers and make
> sure
> they get reassigned? We could also use SET() here, and pass it a callable
> that
> sets it to an extant worker pk, but at the moment I think I prefer

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.

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.

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

But I can live with any of these options as long as we prevent the cascade

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20161117/9f8e322a/attachment.htm>

More information about the Pulp-dev mailing list