O.K. The prepare went through. There are new repositories with missing version_href:
[root@foreman ~]# sudo -u postgres psql foreman -c 'select id,pulp_id,relative_path from katello_repositories where version_href is null;'
id | pulp_id | relative_path
-------+-----------------------------------------------------------------+-----------------------------------------------------------------------------
42880 | 1-centos7-epel7-v244_0-b927ce80-c073-4911-8be6-58da9a55749d | ORG/content_views/centos7-epel7/244.0/custom/foreman-client/2_3_el7_x86_64
42948 | 1-centos7-epel7-Library-b927ce80-c073-4911-8be6-58da9a55749d | ORG/Library/centos7-epel7/custom/foreman-client/2_3_el7_x86_64
42418 | 1-centos7-epel7-v241_0-b927ce80-c073-4911-8be6-58da9a55749d | ORG/content_views/centos7-epel7/241.0/custom/foreman-client/2_3_el7_x86_64
42600 | 1-centos7-epel7-v242_0-b927ce80-c073-4911-8be6-58da9a55749d | ORG/content_views/centos7-epel7/242.0/custom/foreman-client/2_3_el7_x86_64
43173 | 1-centos7-epel7-v246_0-7e2d627c-aaa5-4689-aeff-f34cb7163a19 | ORG/content_views/centos7-epel7/246.0/custom/foreman/2_4_el7_x86_64
43186 | 1-centos7-epel7-v246_0-b927ce80-c073-4911-8be6-58da9a55749d | ORG/content_views/centos7-epel7/246.0/custom/foreman-client/2_3_el7_x86_64
28592 | 1-centos7-epel7-Production-b927ce80-c073-4911-8be6-58da9a55749d | ORG/Production/centos7-epel7/custom/foreman-client/2_3_el7_x86_64
30634 | 1-centos7-epel7-Testing-b927ce80-c073-4911-8be6-58da9a55749d | ORG/Testing/centos7-epel7/custom/foreman-client/2_3_el7_x86_64
43237 | 1-centos7-epel7-Library-7e2d627c-aaa5-4689-aeff-f34cb7163a19 | ORG/Library/centos7-epel7/custom/foreman/2_4_el7_x86_64
43008 | 1-centos7-epel7-v245_0-b927ce80-c073-4911-8be6-58da9a55749d | ORG/content_views/centos7-epel7/245.0/custom/foreman-client/2_3_el7_x86_64
(10 rows)
As expected the “foreman/2_4_el7_x86_64” has the mission version_href as there is also a “foreman-client/2_4_el7_x86_64”.
The migration plan contains the following repositories entries:
{
"name": "centos7-epel7-2_4_el7_x86_64",
"repository_versions": [
{
"pulp2_distributor_repository_ids": [
"1-centos7-epel7-Library-7e2d627c-aaa5-4689-aeff-f34cb7163a19",
"1-centos7-epel7-v246_0-7e2d627c-aaa5-4689-aeff-f34cb7163a19"
],
"pulp2_repository_id": "1-centos7-epel7-v246_0-7e2d627c-aaa5-4689-aeff-f34cb7163a19"
}
]
},
{
"name": "centos7-epel7-2_4_el7_x86_64",
"repository_versions": [
{
"pulp2_distributor_repository_ids": [
"1-centos7-epel7-Library-84701efc-c3fc-4377-8c9c-29da70125868",
"1-centos7-epel7-v246_0-84701efc-c3fc-4377-8c9c-29da70125868"
],
"pulp2_repository_id": "1-centos7-epel7-v246_0-84701efc-c3fc-4377-8c9c-29da70125868"
}
]
},
The 7e2d627c-aaa5-4689-aeff-f34cb7163a19 is the foreman 2.4 repo and the 84701efc-c3fc-4377-8c9c-29da70125868 is the foreman-client 2.4 repo. I guess, because of the order in the migration plan, the latter one will be migrated while the former one will be missing, which makes sense: when it creates objects out of this json it will create an object with the name “centos7-epel7-2_4_el7_x86_64”, the latter overwriting the former one.
Thus, having two (or more) repositories with the identical label in different products in a CV causes issues in the migration as the name set in the migration plan does not include the product.
The repositories itself are not affected as those are listed in the plan by their backend identifier, which is unique.
Now, is this a katello issue or a pulp issue?