<div dir="ltr"><div><div>I took that idea and posted it to issue #2430. I marked it as a sprint candidate if someone wants to groom it.<br><br><a href="https://pulp.plan.io/issues/2430" target="_blank">https://pulp.plan.io/issues/<wbr>2430</a><br><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 17, 2016 at 4:06 PM, Patrick Creech <span dir="ltr"><<a href="mailto:pcreech@redhat.com" target="_blank">pcreech@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>On Thu, 2016-11-17 at 15:33 -0500, Brian Bouterse wrote:<br>
> +1 to taking an action on this. The SET_NULL approach sounds fine with me for now. It is so<br>
> simple. It does not help with the later log analysis though which I do think is useful, but maybe<br>
> not something we need to facilitate with the MVP.<br>
><br>
> To brainstorm another idea, what if instead of deleting workers, we keep those records for much<br>
> longer. With the same reasoning as Task, it would be useful to post-mortem analyze when workers<br>
> are coming on and offline for example. FYI, the Worker table is exclusively managed by<br>
> pulp_celerybeat. We could introduce a online boolean to the Worker model and update<br>
> pulp_celerybeat to mark workers as online/offline instead of deleting them. I don't think this<br>
> would be difficult to do or get right. It would solve the issue of the cascading deletes, provide<br>
> the Task analysis use case, and provide the Worker analysis use case too. I would rather do this<br>
> than add an additional field to Task.<br>
><br>
</span>TLDR: I prefer this<br>
<br>
This is the approach I was just thinking about.  In some environments I've worked in, the 'delete'<br>
general concept even is to set a flag of some sort to manage state instead of deleting the data.  To<br>
add a simple state variable of some kind to the worker would be the most robust solution.  This<br>
allows us to preserve data instead of losing it, etc... <br>
<br>
<br>
> ... but I hope we don't add an additional field to Task.<br>
same here<br>
<span><br>
> We could use SET_NULL for the 3.0 MVP and save this as a future refactor/bugfix. It's probably a<br>
> bug for that field to become NULL when a worker is deleted. What do others think about this?<br>
<br>
</span>I'd prefer to not SET_NULL unless the above suggestion proves too complicated.<br>
<div class="m_-575803409139237129HOEnZb"><div class="m_-575803409139237129h5"><br>
> Thanks for bringing his up; we need to take some action.<br>
><br>
> -Brian<br>
><br>
</div></div><br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div></div>