[Pulp-dev] 3.0 Validation update

[Michael Hrivnak]

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 <jortel at 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 <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
> >
>
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>


-- 

Michael Hrivnak

Principal Software Engineer, RHCE

Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170417/ae69a686/attachment.htm>