On Thu, Jul 11, 2019 at 4:21 PM David Davis <davidda...@redhat.com> wrote:
> ReservedResources are unique[0] and the tasking code relies on this > uniqueness to prevent race conditions[1]. The db transaction prevents two > workers from acquiring a lock on the same resource. I read through 5120 but > I am not sure how the design would prevent that from happening? > > Thanks for pointing this out. How about creating a separate model for keeping track of historical CreatedResource - TaskCreatedResource? We can worry about improving the tasking system performance in a separate story. > [0] > https://github.com/pulp/pulpcore/blob/master/pulpcore/app/models/task.py#L35 > [1] > https://github.com/pulp/pulpcore/blob/ae6be0d89c5df26ac1cfdc876f3b131aa6e9bcf8/pulpcore/app/models/task.py#L229-L246 > > David > > > On Thu, Jul 11, 2019 at 4:04 PM Dennis Kliban <dkli...@redhat.com> wrote: > >> I just wrote up a story to add an ability to filter Tasks by the >> resources that they reserved. This is needed for the migration plan tasks >> and will be just as useful for other tasks. >> >> The design requires storing ReservedResources permanently in the >> database. The status of the task associated with the ReservedResource will >> be used to determine if a ReservedResource is still active or not. >> Additionally it will no longer be necessary to dispatch a task for removing >> the ReservedResource. Pulp will no longer have to dispatch 2 tasks for >> every single task with a reservation. >> >> What questions or concerns do you have? >> >> [0] https://pulp.plan.io/issues/5120 >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
