[Pulp-dev] repo_id in content unit keys

[Michael Hrivnak]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20171110/5db518a1/attachment.htm>