Re: [Pulp-dev] pulpcore release freeze and release timeline details

[Ina Panova]

Brian,
Thank you for the provided details.

Ack, on releasing pulp_container on Dec 12.

On Thu, 5 Dec 2019, 18:52 Brian Bouterse,  wrote:

> Releasing takes time, and we need pulpcore to be available before the
> releasing of plugins can start. Here's a proposed timeline to allow that to
> happen.
>
> Dec 10 - 22:00 all code merged to 'master'
> Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to pypi.
> Announce only to pulp-dev (not the official announcement)
> Dec 12 - pulp_rpm, pulp_container release
> Dec 12 - the docs.pulpproject.org and pulpproject.org website changes are
> applied
> Dec 12 - Send out announcement to pulp-dev, twitter, and blog
>
> @ttereshc and @ipanova how does this look to you for releasing pulp_rpm
> and pulp_container on the 12th?
>
> Any feedback or adjustment is welcome; please let me know.
>
> Thanks!
> Brian
>
> ___
> 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] pulpcore release freeze and release timeline details

[Brian Bouterse]

Releasing takes time, and we need pulpcore to be available before the
releasing of plugins can start. Here's a proposed timeline to allow that to
happen.

Dec 10 - 22:00 all code merged to 'master'
Dec 11 - pushing pulpcore 3.0.0 GA to pypi, then pulp_file 0.1.0 to pypi.
Announce only to pulp-dev (not the official announcement)
Dec 12 - pulp_rpm, pulp_container release
Dec 12 - the docs.pulpproject.org and pulpproject.org website changes are
applied
Dec 12 - Send out announcement to pulp-dev, twitter, and blog

@ttereshc and @ipanova how does this look to you for releasing pulp_rpm and
pulp_container on the 12th?

Any feedback or adjustment is welcome; please let me know.

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

[Pulp-dev] RPM plugin meeting notes

[Tatiana Tereshchenko]

Pulp 2:

   -

   Sat 6.6 publish performance issue bug(s) - investigating
   -

  1770940 
  -

  1773601 


Pulp 3:

   -

   Blockers https://pulp.plan.io/projects/pulp_rpm/issues?query_id=139
   -

  Performance
  -

 Increased batch-sizes has direct impact
 -

Configure per-plugin - maybe
-

Increase default in pulpcore stages api
-

 Fabricio found one more source of memory problem (pulpcore)

 
https://github.com/pulp/pulpcore/blob/master/pulpcore/app/models/repository.py#L473
 -

 Publish has similar pattern for the performance problem
 -

 Decrease worker-heartbeat writes to DB (~30% overhead?) (pulpcore)
 -

Might be an artifact of the sampling method. Would like to see
verification from cProfile before we change anything.
Heartbeat is in a
separate thread so if it’s waiting on IO, it doesn’t
really matter (dalley)
- UpdateRecord was saved one by one and not in batches, PR is
 posted
 -
  -

  Model level validation
  -

 Not sure full_clean is the correct solution
 -

 ttereshc will check how much plugin is currently affected
 - Comps publish issue
 - root cause not found yet
 - dawalker to send email with the current state of things for
 someone to pick up or collaborate on
  -

  Docs
  -

  Installer (libcomps)
  -

 On sprint, needs to be picked up - mikedep333 will take care of it
 -

 Current state - CentOS7 doesn’t install libcomps
 - Release
 - next RC when the code changes are ready
- optimistically - tomorrow, realistically - next week


   - Open PRs:
  - https://github.com/pulp/pulp_rpm/pulls


Triage:

Un-triaged bugs https://pulp.plan.io/projects/pulp_rpm/issues?query_id=30
___
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

[David Davis]

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