Following up on a recent discussion, here is some background on why "repo_id" appears in the unit key for some content types.
The first step when we model a particular kind of content in Pulp, such as a puppet module, is to establish what attributes can be used for unique identification globally. We call this the "unit key". Using a puppet module as an example, the unit key is the name, author, and version. For example, we can uniquely identify a puppet module with name "stdlib", author "puppetlabs", and version "4.21.0". Pulp will only store one copy of it on disk, and only one record of it in the database. There are some types of content in Pulp where it is impossible to define uniqueness globally. This category of content usually has a scope of relevance that is limited to a single repository. An example is a "PackageGroup" in a yum repository. It is a trackable piece of data that needs to go through the same curation and promotion workflows as RPMs. But it does not have any globally-unique properties. In order to facilitate this concept, Pulp 2 adds the "repo_id" to the unit key for such unit types. A unique "PackageGroup" in Pulp 2 is identified by its name and a repo_id. When copying a PackageGroup to a destination repository, a new unit must be created and saved in the database with the destination repository's repo_id. Tags in pulp_docker work similarly. When "promoting" a tag to a new repository, Pulp either creates a new unit record that contains the destination's repo_id, or it overwrites an existing tag of the same name. There may be another way for us to handle this, but that is the background for why a "copy" operation creates new units for some types of content. Let me know what questions you have. -- Michael Hrivnak Principal Software Engineer, RHCE Red Hat
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
