RPM Support

While investigating the productid problem Katello is experiencing, I took a look at the ``yum_repo_metadata_file`` model.

The unit key for this content unit is ('data_type', 'repo_id'). Obviously, this is not going to be unique. For a productid file, ``data_type = 'productid'``. If you happen to copy a second file of the same type into the repository, or if the upstream repository being synced has two files of the same type, Pulp will treat them as the same unit. This makes no sense.

When copying, this causes files to be overwritten in /var/lib/pulp/content/ silently (I suspect because there is "special" behaviour for this unit type). Underlying files will change and Pulp doesn't know and has no way to recover.

To see this in action:

1. Sync two repositories with productids, or upload two yum_repo_metadata_file content units.
2. Make a third repository: ``pulp-admin rpm repo create --repo-id temp``
3. Copy from the first repo: ``pulp-admin rpm repo copy metafile --from-repo-id el6-updates --to-repo-id temp``
4. Checksum the file associated with the unit in /var/lib/pulp/content
5. Copy from the second repo: ``pulp-admin rpm repo copy metafile --from-repo-id el7-updates --to-repo-id temp``
6. Checksum the file again (it's going to be the same path, probably ``/var/lib/pulp/content/units/yum_repo_metadata_file/62/7145ed1fac7340e78687188d35142824b140825a2e70ba3135317b8cf70961/productid.gz``, because the path is derived from the unit key)

For bonus points, inspect all the units in the database:

1. mongo pulp_database
2. db.units_yum_repo_metadata_file.find().pretty()

Note none of the units actually reference the new file anyway and actually reference the path for the unit it was copied from:

{
    "_id" : "4f55aa36-8b7b-48a3-a0dc-fc12aa3e414c",
    "pulp_user_metadata" : {

    },
    "_last_updated" : 1463838950,
    "_storage_path" : "/var/lib/pulp/content/units/yum_repo_metadata_file/b1/5f7988ebaa45d1306b7b804d1229107c83f631305f1a1cc583347a220600c7/productid.gz",
    "downloaded" : true,
    "data_type" : "productid",
    "repo_id" : "el7-updates",
    "checksum" : "59e34cd37839bae40bc66079dccec6afdb781d27",
    "checksum_type" : "sha1",
    "_ns" : "units_yum_repo_metadata_file",
    "_content_type_id" : "yum_repo_metadata_file"
}
{
    "_id" : "68dd3a99-2d5a-4d63-bd20-84396e808898",
    "pulp_user_metadata" : {

    },
    "_last_updated" : 1463839004,
    "_storage_path" : "/var/lib/pulp/content/units/yum_repo_metadata_file/8f/da3a9f092b0b717c48f8eda7f6f5deb4cefe0786216449d693023d5a9d8bae/productid.gz",
    "downloaded" : true,
    "data_type" : "productid",
    "repo_id" : "el6-updates",
    "checksum" : "276976ed33fe7502357c4502147656f6cd2d9a1e",
    "checksum_type" : "sha1",
    "_ns" : "units_yum_repo_metadata_file",
    "_content_type_id" : "yum_repo_metadata_file"
}
{
    "_id" : "fd1f4296-6ec9-4954-a289-03d7453d01a9",
    "pulp_user_metadata" : {

    },
    "_last_updated" : 1463840904,
    "_storage_path" : "/var/lib/pulp/content/units/yum_repo_metadata_file/8f/da3a9f092b0b717c48f8eda7f6f5deb4cefe0786216449d693023d5a9d8bae/productid.gz",
    "downloaded" : true,
    "data_type" : "productid",
    "repo_id" : "temp",
    "checksum" : "276976ed33fe7502357c4502147656f6cd2d9a1e",
    "checksum_type" : "sha1",
    "_ns" : "units_yum_repo_metadata_file",
    "_content_type_id" : "yum_repo_metadata_file"
}

If you happen to orphan either one of this units, the storage of the other will be blown away during an orphan cleanup.