<div dir="ltr">That's a very likable approach. Delete immediately and auto-cancel any tasks queued or in progress. It's simple.</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Apr 17, 2017 at 3:22 PM, Jeff Ortel <<a href="mailto:jortel@redhat.com" target="_blank">jortel@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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: <div class="HOEnZb"><div class="h5">> > > On Mon, Apr 17, 2017 at 1:26 PM, Brian Bouterse <<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a> <mailto:<a href="mailto:bbouters@redhat.com">bbouters@redhat.com</a>>> 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 > > > </div></div><div class="HOEnZb"><div class="h5">> _______________________________________________ > Pulp-dev mailing list > <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> > <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> > </div></div> _______________________________________________ Pulp-dev mailing list <a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a> </blockquote></div> <div> </div>-- <div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Michael HrivnakPrincipal Software Engineer, RHCE Red Hat</div></div> </div>