> > I think everyone seems to be leaning in the direction that update does > not [need to be a task].
I am leaning that updates and deletes should be tasks for importers and publishers in order to get the full benefit of the reserved resource system. The most important point is that related work will be done in a predictable order. > Delete could be a little more challenging, because of the potential desire > for an importer or publisher to want to update attributes on it, like the > last time a sync succeeded. Maybe we can manage to avoid the need for a > plugin to write to its config, which also seems like a very reasonable > goal, but that again could be part of the plugin API discussion. Although > thinking about relationships that are likely to exist in the database, > having an importer or publisher disappear while a corresponding task is > running sounds like it could cause a lot of potential problems. > Deletes are simplest if they aren't allowed to "cut in line". Then it is the user's responsibility to ask Pulp to do work in a reasonable order, and failures will be deterministic. Another scenario comes up because we removed overrides from our MVP. A workaround would be: Update to temp config, sync, update back to old config. If update and delete are synchronous, the user would have to monitor the state of the sync task, and could not issue the second update request until the sync task is complete (or at least started).
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
