I took that idea and posted it to issue #2430. I marked it as a sprint candidate if someone wants to groom it.
https://pulp.plan.io/issues/2430 On Thu, Nov 17, 2016 at 4:06 PM, Patrick Creech <[email protected]> wrote: > 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 > > > > _______________________________________________ > 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
