# depsolve usecases The following are usecases our users want, based on direct conversations w/ actual users and TAMs. ## Cases ### "I want a RHEL8.1 version of the RHEL8 repo" * how? * "rhel8 RPMs with no errata attached (rhel8-release), plus RPMs mentioned in errata as of (rhel8-release-date)" * depsolve-yes, why? * "rpms w/out errata" sometimes results in non-release-day RPMs, which can't be installed w/out their dependencies * depsolve-no, why? * "all rpms from date-0 to date-N" should be as complete as the repo was on date-N * depsolve is only needed in cases where we're pulling in RPMs the user doesn't want anyway * questions ### "I want RHEL8.1 plus security-errata (only) as of (date)" * how? * start with the above for RHEL8.1 * find all security-errata post-RHEL8.1 * add all the RPMs mentioned therein * depsolve-yes, why? * later security-errata may (often do) depend on later RPMs, and won't install w/out dependencies * questions ### I want RHEL8.1 *plus* these specific NEVRAs from Later" * how? * RHEL8.1 from above * add specific RPMs * depsolve-yes, why? * see "plus security errata" - the later RPMs may not be installable w/out unmentioned dependencies * depsolve-no, why? * potentially may bring in many new RPMs unexpectedly * questions ### "I want RHEL8.1, but NOT THESE RPMs" * how? * start with the above for RHEL8.1 * remove the specified RPMs * depsolve-no, why? * removing RPMs may make repoclosure impossible - and that must be, by definition, "OK" for this use-case * questions
Last changed by  
 
Grant Gainey
62

Read more

pulp-cli import/export command proposal

Related Issues: Incremental-FS-export Clean up import/export CLI Add fs-exporter to CLI Executive Summary There are two kinds-of Exporters in use, PulpExporter and FilesystemExporter. There is currently just one import-type, PulpImporter and PulpImport.

1/24/2023
Pulp3 Import/Export Design

Introduction/problem statement There is a use-case for extracting repository-versions out of a running instance of Pulp into a file that can be transferred to another Pulp instance and imported. This is not the Pulp-to-Pulp sync case; the assumption is that the receiving Pulp instance is network-isolated. This design aims to describe the requirements, limitations, and a possible implementation for this functionality. Additional Documents low level design document

1/24/2023
PulpImport/Export Memory Investigation

Problem statement Large datasets are serialized in memory before written to disk. json.dump cannot be tricked to loop over itertators (in any sane way) django_import/export export() returns a list in memory instead of a lazy iterator. This is a real problem "in the wild" with actual Red Hat data and users - we need a short-term solution, ASAP Proposed solutions Export in chunks Write "[" to a tempfile Call export(...).json.encode(...) on chunks of our queryset (which will be a string with json-list starting/ending with "[]")

1/24/2023
Pulp3 Import/Export: Handling entities without a 'natural' key

Executive Summary Pulp Import/Export cannot rely on pulp_id to differentiate objects at import-time, due to pulp_id being 'owned' by the downstream instance, not the upstream. We propose adding a field to Content for the use of Pulp Import/Export, export_id, to give us a way to be able to use an upstream-pulp-id to identify entities created downstream, in order to be able to rebuild relationships. Introduction The PulpImport/Export (PIE) feature is aimed at allowing the export of repository content and artifacts from one Pulp instance ("upstream") in a way that allows them to be transported to another Pulp instance ("downstream"), such that "downstream" ends up with a Repository/Repositories with RepositoryVersions that contain the same Content as the exported "upstream" had. PIE accomplishes this in two ways.

1/24/2023
Read more from Grant Gainey
Published on HackMD