I'm still in favor of having both update and delete operations synchronous for these reasons:
1. Simpler. 2. Getting a 201 on a resource delete/update seems odd from the REST point of view. 3. We want update/delete to be immediate and we'd want any task in progress to discontinue as soon as possible. Basically, error out. 4. Image these tasks queued up [SYNC][SYNC][SYNC][DEL] ... we'd waste a ton of cycles syncing a repo that the user wants to delete. And, the delete get's delayed by hours. Not what the user intended. On 04/17/2017 12:55 PM, Michael Hrivnak wrote: > > > On Mon, Apr 17, 2017 at 1:26 PM, Brian Bouterse <bbout...@redhat.com > <mailto:bbout...@redhat.com>> wrote: > > @asmacdo, your points cause me to also think that all importer/publisher > update and delete operations > should be tasks that use the tasking reservations system. That will cause > them to never run while a sync > or publish for instance is running. I'm interested in hearing more > thoughts on this from others. > > > Doing updates and deletes in tasks keeps the Pulp 2 behavior, which is safe > and reasonably well-understood. > That's a fine way to go. > > I think the delete is especially advantageous to do in a task, so the object > never disappears while an import > or publish related task is running. > > Update is easier to do synchronously. If it's a task, we have to worry about > saving a diff for the object > (presumably as an argument to the task), then applying that diff in the > running task and validating it the way > the REST API would. That's doable, but we'd have to do it. :) It's very > tempting to do it synchronously and > let the REST API do what it does for free. > > That said, just because it's the easy option doesn't mean it's the right one. > Doing the update synchronously, > as has been pointed out, allows for the possibility that the importer config > will change between when the task > is queued and when it runs. I think that's fine and reasonable, but it could > be seen as a downside. > > Consider that while doing an update in a task could be more predictable in > one way, it could also create its > own confusion. Consider an API user who sees a representation of an importer > in the DB and submits changes to > it, but doesn't realize there are already other changes queued as tasks. > > Neither approach seems perfect, but I lean toward synchronous updates to > avoid the diff+validation challenge > and the (potentially very long) delay in changes being visible. > > > > A related question... are importers or publishers ever shared with > multiple repos in Pulp3? > > > Nope. > > > -- > > Michael Hrivnak > > Principal Software Engineer, RHCE > > Red Hat > > > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
