That's a very likable approach. Delete immediately and auto-cancel any tasks queued or in progress. It's simple.
On Mon, Apr 17, 2017 at 3:22 PM, Jeff Ortel <jor...@redhat.com> wrote: > 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 > > > > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > > -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev