Re: [Pulp-dev] Pulp 3 demos and docs

[David Davis]

*Bump*. Last week we decided we still wanted to do demo videos even though
they won't be ready with the 3.0 release. Since etherpad.net is shutting
down, I've moved the pad here:

https://hackmd.io/axqigIBLS3609Y84rPY1rA?edit

Please add more ideas and/or put your name next to any topics you'd like to
demo.

David


On Fri, Nov 15, 2019 at 11:02 AM David Davis  wrote:

> Two items we discussed preparing for the Pulp 3.0 GA release were a series
> of demo videos showcasing Pulp 3's features and also documentation for Pulp
> (both core and plugins). I wanted to start a discussion around both.
>
> # Demo Videos
>
> I'm imagining that we'll create a series of short (2-5 min) demo videos
> that will each showcase one of Pulp 3's features. I'm hoping that each Pulp
> team member could create one. We could share these on youtube, create a
> playlist, and link to the videos from our release announcement. I've
> started a list to track topic ideas and ask for volunteers.
>
> https://etherpad.net/p/pulp-3.0-demos
>
> # Docs
>
> I created an etherpad to track docs tasks that are in need of a person to
> work on them before the 3.0 GA. This could be sort of a backlog for our
> demo/docs day (see below) if people are looking for stuff to work on. I'm
> imagining it would capture both core and the plugins we're planning to
> release on Dec 3.
>
> https://etherpad.net/p/pulp-3.0-docs
>
> # Demo/Docs Day
>
> I've heard people say that it'd be helpful to have a day where we can all
> collaborate on demos and docs. I'm a bit indifferent about this idea but I
> can organize this if enough people are interested. If you're interested,
> please respond here or offline to let me know which day(s) work for you.
>
> Any input on any of the above topics is greatly appreciated.
>
> David
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

[Pulp-dev] Sprint 63 Meeting Minutes

[Robin Chan]

5-Dec-2019

Stats on how we did in previous 3 week sprint Sprint 62 Query
:

Sprint 62

17 New

8 Assigned

13 Post

36 Modified

1 Closed - NOTABUG

2 Closed - COMPLETE

https://pulp.plan.io/issues?query_id=124

Action Items from last Sprint Planning

   -

   Rchan: clear sprint candidates (note haven’t been doing this)


Dates:

https://pulp.plan.io/projects/pulp/wiki/Sprint_Plans

Sprint candidates:

https://pulp.plan.io/issues?query_id=26

Current sprint Sprint 62 Query 

Anything not moving forward?

Pending Items:

   -

   Migration plugin issues found during early testing
   -

   CI improvement highest priority items


Action Items:

   -

   rchan: clear Sprint Candidate https://pulp.plan.io/issues?query_id=26
   - Will do this at end of week
   -

   rchan: send out planning minutes
   -

   Sync w/dennis on dates of docker
   -

   David will send email to pulp-dev on ideas


Robin Chan

She/Her/Hers

Satellite Software Engineering Manager - Pulp

Red Hat 

IRC: rchan

___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] RPM file list can be confusing for users

[Tatiana Tereshchenko]

In my opinion, it's fine to show exactly what we have/store.
Maybe we can add some clarification to the docs about the format of the
filelists.

On Mon, Dec 9, 2019 at 11:09 AM Pavel Picka  wrote:

> There is the issue for $subject #5831 [0], I took a look at
> createrepo_c [1] and 'dir', 'ghost' or 'None/[null]' are the file
> types.
> It means some of the paths are only directories, others are files
> themselves.
>
> I would like to ask if we want to show it to users or adjust the
> serializer to show only files and not directories?
>
> [0] https://pulp.plan.io/issues/5831
> [1]
> http://rpm-software-management.github.io/createrepo_c/c/structcr___package_file.html
>
> --
> Pavel Picka
> Red Hat
>
>
> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev

Re: [Pulp-dev] Required fields for models at the DB level

[Tatiana Tereshchenko]

+1 to have additional serializer for validation content fields and use
current serializers for upload case
+1 to validate during sync

On Fri, Dec 6, 2019 at 8:31 PM David Davis  wrote:

> I talked to @ttereshc this afternoon and a couple questions came up.
>
> First, in pulp_rpm we have a PackageSerializer[0] that handles creating
> and displaying packages. The problem is that the package field values are
> derived from the artifact and not the user so most fields are readonly and
> not required. I'm imagining we'll have to split this serializer in two (ie
> a PackageSerializer and a PackageUploadSerializer) in order to use it to
> validate package data. Does that make sense or is there a better way?
>
> Secondly, I don't think we're validating data during sync. What if a user
> syncs data from a remote that has bad data? I think we'll need to have the
> stages somehow use serializers as well? If others agree, I can file an
> issue.
>
> [0]
> https://github.com/pulp/pulp_rpm/blob/326d189bbae9267d59282d62ada1fa36467a2d8f/pulp_rpm/app/serializers.py#L69
>
> David
>
>
> On Thu, Dec 5, 2019 at 6:32 AM David Davis  wrote:
>
>> This makes sense to me. I wonder if we should document what you've
>> outlined in the plugin writers guide? If so, then maybe we should repurpose
>> 5828?
>>
>> David
>>
>>
>> On Tue, Dec 3, 2019 at 12:14 PM Brian Bouterse 
>> wrote:
>>
>>> After some IRC discussion during open floor, I think the consensus is
>>> that we should not have BaseModel call full_clean(). Plugin writers doing a
>>> lot of object creation without involving DRF serializers should call
>>> full_clean() either in application code or their specific model's save()
>>> method. Here's some recap about the motivations for this:
>>>
>>> * By having full_clean() called with all model save it gives Pulp "two
>>> validation layers" when there only needs to be one. DRF's validation layer
>>> is the serializer, and it isn't prepared to do error handling from a
>>> "second" layer. This is partly an echo of the concerns from Tom Christie's
>>> writing.
>>> * DRF is primarily designed to have data flow through its serializers.
>>> This issue is more problematic in cases where data is not flowing through
>>> the serializer. Thus we should try to include the serializer whenever
>>> possible.
>>> * If we cannot include the serializer, those are cases where we would
>>> specifically benefit from calling full_clean manually.
>>>
>>> Other thoughts and concerns are welcome. If nothing major comes up then
>>> we can close https://pulp.plan.io/issues/5828 as WONTFIX.
>>>
>>>
>>>
>>> On Mon, Dec 2, 2019 at 6:52 PM Simon Baatz  wrote:
>>>
 On Mon, Dec 02, 2019 at 03:53:06PM -0500, Brian Bouterse wrote:
 >If anyone has concerns with us enabling Model validation by
 default on
 >all models please let us know soon.

 I don't know (yet) if I have concerns, but DRF seems to have, see

 https://www.django-rest-framework.org/community/3.0-announcement/#differences-between-modelserializer-validation-and-modelform

 According to DRF's design, all validation logic should be at one
 place, which is the serializer.  This seems to be a controversial
 issue, see e.g.
 https://github.com/encode/django-rest-framework/issues/3144.  From
 that issue:

 What happens in the case where in your models you are forcing a
 full_clean (perhaps by including it in the save method)?  Will
 serializers know how to handle an exception from an explicit
 full_clean?

 And Tom Christie's answer:

 I'd recommend that application level validation should generally
 happen prior to save, not during it.  Personally I'd avoid
 full_clean, and instead ensure that state changing operations on
 model instances are only ever made via method calls that can provide
 a boundary that ensures that only valid state changes may ever be
 made by the rest of the application.



 We need to be aware that we are leaving the path recommended by DRF
 if we implement this proposal and mix Django validation and DRF
 validation.  Unfortunately, I don't know what the alternative is.
 Using DRF serializers to construct all model instances looks clumsy
 when it comes to relations.

 ___
>>> Pulp-dev mailing list
>>> Pulp-dev@redhat.com
>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>
>> ___
> Pulp-dev mailing list
> Pulp-dev@redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
___
Pulp-dev mailing list
Pulp-dev@redhat.com
https://www.redhat.com/mailman/listinfo/pulp-dev