Re: [Pulp-dev] 3.0 Validation update

tldr; REST calls to Update or Delete Importers, Publishers, and Repositories will return *asynchronously*. We met last week to discuss the question. The case of a Delete called during a sync demonstrates why this is necessary. If Deletes were synchronous, each plugin would have to handle the

Re: [Pulp-dev] 3.0 Validation update

On 04/25/2017 02:47 PM, Brian Bouterse wrote: > There are a few use cases and behaviors that I think only an asynchronous > update/delete for importers, > publishers, and repositories will satisfy. Thanks to @asmacdo for covering > some of these also. > > * As a plugin writer, I am in control

Re: [Pulp-dev] 3.0 Validation update

I wrote a response inline. On Mon, Apr 24, 2017 at 3:12 PM, Jeff Ortel wrote: > > > On 04/21/2017 01:16 PM, Austin Macdonald wrote: > > I think we have arrived at a consensus around these points: > > +1 > > > > > * Django's ModelForm validations that are used during

Re: [Pulp-dev] 3.0 Validation update

I think we have arrived at a consensus around these points: * Django's ModelForm validations that are used during `full_clean` is an anti-pattern in DjangoRestFramework and should not be used * Validation, by our definition, will be done by the serializers in the API layer * The Task layer should

Re: [Pulp-dev] 3.0 Validation update

On 04/14/2017 10:23 AM, Brian Bouterse wrote: > Did we ever decide on if delete and modify operations on an importer would be > synchronous API operations or > tasking system tasks? > > From what I'm reading, there isn't a MVP need (and maybe ever) to verify the > feed is set at the sync API

Re: [Pulp-dev] 3.0 Validation update

On 04/17/2017 09:50 AM, Michael Hrivnak wrote: > That MVP scoping sounds reasonable. > > I'm not sure we decided 100% on whether those operations need to be tasks, > but I think everyone seems to be > leaning in the direction that update does not. But it partly will come down > to a plugin

Re: [Pulp-dev] 3.0 Validation update

On Mon, Apr 17, 2017 at 1:26 PM, Brian Bouterse 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 >

Re: [Pulp-dev] 3.0 Validation update

On 04/17/2017 01:26 PM, Brian Bouterse 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.

Re: [Pulp-dev] 3.0 Validation update

@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

Re: [Pulp-dev] 3.0 Validation update

> > I think everyone seems to be leaning in the direction that update does > not [need to be a task]. I am leaning that updates and deletes should be tasks for importers and publishers in order to get the full benefit of the reserved resource system. The most important point is that related

Re: [Pulp-dev] 3.0 Validation update

Did we ever decide on if delete and modify operations on an importer would be synchronous API operations or tasking system tasks? >From what I'm reading, there isn't a MVP need (and maybe ever) to verify the feed is set at the sync API call and in the task. We definitely need to do that business

Re: [Pulp-dev] 3.0 Validation update

On 04/11/2017 05:08 PM, Michael Hrivnak wrote: > I like thinking about this as business logic. Data may be valid, but it may > not be usable in a particular context. > > To help figure out where such logic should live, it may help to think about > where the check is most important. I've described

Re: [Pulp-dev] 3.0 Validation update

On 04/11/2017 03:49 PM, Austin Macdonald wrote: > Where should business logic live? As an example, I want to consider the > sync task [0] and the need to ensure that an importer is syncable. For now, > let's say that an importer is syncable if it has a feed_url. > > Since the call to sync an

Re: [Pulp-dev] 3.0 Validation update

I like thinking about this as business logic. Data may be valid, but it may not be usable in a particular context. To help figure out where such logic should live, it may help to think about where the check is most important. I've described that time as "at the time of use" earlier in this

Re: [Pulp-dev] 3.0 Validation update

Where should business logic live? As an example, I want to consider the sync task [0] and the need to ensure that an importer is syncable. For now, let's say that an importer is syncable if it has a feed_url. Since the call to sync an importer comes from the API, the earliest we can check that

Re: [Pulp-dev] 3.0 Validation update

On 04/07/2017 12:08 PM, Brian Bouterse wrote: > == questions == > * Where should ^ terms be documented? I'm not really sure, but recommend the wiki as a good starting point for putting information that we should probably "officially" document *somewhere*, but at the moment we aren't quite sure

Re: [Pulp-dev] 3.0 Validation update

Thanks @smyers and asmacdo. This convinces me that we should just use the DRF serializer for all validation and expect that full_clean() is not the authority on what it means to be validated. I was really holding out on full_clean, but I can see now that we should go wholesale into DRF

[Pulp-dev] 3.0 Validation update

tldr; 1. Serializer errors won't be caught by serializer validation. 2. DRF does not use full_clean(), so if data passes serializer validation, it gets into the db. 3. We can use full_clean for process level validation. During a lengthy discussion on IRC, I incorrectly asserted that