[Pulp-dev] pulp3: task - worker relationship

Brian Bouterse bbouters at redhat.com
Fri Nov 18 15:33:48 UTC 2016


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 <pcreech at redhat.com> 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
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20161118/bb96de54/attachment.htm>


More information about the Pulp-dev mailing list