[Pulp-dev] 3.0 Validation update

[Brian Bouterse]

I think the auto-cancel will be an unexpected side-effect. For instance a
user who wants an importer/publisher change to occur after a sync is done.
(retelling @asmacdo's argument here) Auto-canceling would require the user
to monitor for the sync task instead of just firing them in the order the
user wants Pulp to handle them.

+1 for the asynchronous update and delete operations for
importers/publishers. It gives a transactional like experience for plugin
writers which is really nice. For synchronous deletes having the plugin
writer not being able to rely on the data layer being consistent during the
sync or publish does not sound good. Having it error in random places due
to a synchronous delete doesn't sound like a good user experience either.

For the [SYNC][SYNC][SYNC[DEL] case the user can issue explicit cancels if
they want the delete to be handled immediately. They have everything they
need to get the behaviors they want out of Pulp.

Also there are write-write concern with synchronous updates. The importer
read at the beginning of a sync could then cause a write which would
overwrite a synchronous update done via the API.

These are some of the reasons that make me thing asynchronous update and
delete operations on publishers, importers, and repositories are the way to
go.

On Mon, Apr 17, 2017 at 4:03 PM, Austin Macdonald <austin at redhat.com> wrote:

> 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.
>>
>
> I assumed the opposite. If I issue 3 syncs and then a delete, I wouldn't
> expect the syncs to be canceled. If we do decide to go with synchronous
> update/delete, we have to account for the possibility that the content
> adapter has been modified or removed through the whole sync and publish
> process. I think that would force us to disallow (or just a strongly worded
> note) warning them not to reload or save content adapter instances, or else
> they will be susceptible to race conditions. Because the plugin writer is
> now responsible for handling race conditions and failing gracefully, I I am
> thinking that it will not be simpler.
>
> 2. Getting a 201 on a resource delete/update seems odd from the REST point
>> of view.
>
>
> Yeah :(
>
> I am -0 on synchronous calls at the moment but I could be convinced
> otherwise. I think of this primarily as balancing predictability vs
> performance.
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170417/affc5f16/attachment.htm>