----- Original Message ----- > +1 to taking an action on this. The SET_NULL approach sounds fine with me for > now. It is so simple. It does not help with the later log analysis though > which I do think is useful, but maybe not something we need to facilitate > with the MVP. > > To brainstorm another idea, what if instead of deleting workers, we keep > those records for much longer. With the same reasoning as Task, it would be > useful to post-mortem analyze when workers are coming on and offline for > example. FYI, the Worker table is exclusively managed by pulp_celerybeat. We > could introduce a online boolean to the Worker model and update > pulp_celerybeat to mark workers as online/offline instead of deleting them. > I don't think this would be difficult to do or get right. It would solve the > issue of the cascading deletes, provide the Task analysis use case, and > provide the Worker analysis use case too. I would rather do this than add an > additional field to Task. > > I would be fine with either of ^ approaches, but I hope we don't add an > additional field to Task. We could use SET_NULL for the 3.0 MVP and save > this as a future refactor/bugfix. It's probably a bug for that field to > become NULL when a worker is deleted. What do others think about this?
I would prefer that we add a boolean to the worker models that indicated the online/offline state. > > Thanks for bringing his up; we need to take some action. > > -Brian > > > > On Thu, Nov 17, 2016 at 10:03 AM, Jeff Ortel < [email protected] > wrote: > > > > > On 11/16/2016 05:27 PM, Sean Myers 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. > +1 > > > > > 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 > > SET_NULL. > > > > _______________________________________________ > > Pulp-dev mailing list > > [email protected] > > https://www.redhat.com/mailman/listinfo/pulp-dev > > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > > > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > _______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
