Pulp 2: -
Sat 6.6 publish performance issue bug(s) - investigating - 1770940 <https://bugzilla.redhat.com/show_bug.cgi?id=1770940> - 1773601 <https://bugzilla.redhat.com/show_bug.cgi?id=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