[Pulp-dev] 3.0 Validation update

[Jeff Ortel]

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 <bbouters at redhat.com <mailto:bbouters at 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 847 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170417/5170fc63/attachment.sig>