On Thu, 2016-11-17 at 15:33 -0500, Brian Bouterse wrote: > +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. > TLDR: I prefer this
This is the approach I was just thinking about. In some environments I've worked in, the 'delete' general concept even is to set a flag of some sort to manage state instead of deleting the data. To add a simple state variable of some kind to the worker would be the most robust solution. This allows us to preserve data instead of losing it, etc... > ... but I hope we don't add an additional field to Task. same here > 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'd prefer to not SET_NULL unless the above suggestion proves too complicated. > Thanks for bringing his up; we need to take some action. > > -Brian >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
