Description of problem: Recently the product names for OSP changed in the CDN from "Red Hat OpenStack..." to "Red Hat Enterprise Linux Openstack...". This caused us on RHCI to experience errors when trying to enable new repos after importing a new manifest: Oct 12 16:12:06 sat61dev pulp: pulp.plugins.pulp_rpm.plugins.distributors.yum.configuration:ERROR: Relative URL [Default_Organization/Library/content/dist/rhel/server/7/7Server/x86_64/openstack-director/7.0/os] for repository [Default_Organization-Red_Hat_OpenStack-Red_Hat_Enterprise_Linux_OpenStack_Platform_7_0_director_for_RHEL_7_RPMs_x86_64_7Server] conflicts with existing relative URL [Default_Organization/Library/content/dist/rhel/server/7/7Server/x86_64/openstack-director/7.0/os] for repository [Default_Organization-Red_Hat_OpenStack-Red_Hat_OpenStack_7_0_for_RHEL_7_Platform_director_RPMs_x86_64_7Server] Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) Exception adding distributor to repo [Default_Organization-Red_Hat_OpenStack-Red_Hat_Enterprise_Linux_OpenStack_Platform_7_0_director_for_RHEL_7_RPMs_x86_64_7Server]; the repo will be deleted Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) Traceback (most recent call last): Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) File "/usr/lib/python2.7/site-packages/pulp/server/managers/repo/cud.py", line 187, in create_and_configure_repo Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) distributor_id) Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) File "/usr/lib/python2.7/site-packages/pulp/server/managers/repo/distributor.py", line 184, in add_distributor Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) raise PulpDataException(message) Oct 12 16:12:06 sat61dev pulp: pulp.server.managers.repo.cud:ERROR: (9488-74560) PulpDataException: Relative URL [Default_Organization/Library/content/dist/rhel/server/7/7Server/x86_64/openstack-director/7.0/os] for repository [Default_Organization-Red_Hat_OpenStack-Red_Hat_Enterprise_Linux_OpenStack_Platform_7_0_director_for_RHEL_7_RPMs_x86_64_7Server] conflicts with existing relative URL [Default_Organization/Library/content/dist/rhel/server/7/7Server/x86_64/openstack-director/7.0/os] for repository [Default_Organization-Red_Hat_OpenStack-Red_Hat_OpenStack_7_0_for_RHEL_7_Platform_director_RPMs_x86_64_7Server] Version-Release number of selected component (if applicable): All How reproducible: Always Steps to Reproduce: 1) upload an old manifest that contains the before-change reposet names 2) enable the repos 3) sync (maybe?) 4) disable repos 5) refresh manifest / upload new manifest with new reposet names 6) enable repos again Actual results: Error. Expected results: Preferably, Satellite should handle the name change.
Hi David, can you attach the manifest to the BZ? Also, is there a workaround for handling the scenario when the error?
Once you've disabled the old repos, there is no workaround (other than go into the database and removing the old content). I guess the workaround would be not to disable your old repos and then enable them again if the product name in the manifest changes but not sure customers would be knowledgeable enough to do avoid that.
Moving 6.2 bugs out to sat-backlog.
This doesn't look like a Pulp bug. Here's what I think happened: Katello tried to configure two different Pulp repositories to publish at the same location on the filesystem. Pulp doesn't allow that for obvious reasons, and thus returned an error. I can imagine that if the name of the repo changed in the manifest, it might be difficult for Katello to figure out that it needed to update/modify an existing repo, or at least delete the old one before re-creating it as the new one. Justin, what do you make of this?
yes, what you said is mostly correct. Its not really the name of the repo that is important, but the fact that two different content sets were imported from manifests that had the same location on the cdn (and thus we tried to make two repos in pulp with the same location on the local filesystem). This is not 'fixed' other than we expect these content sets to not change.
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.
The same problem is with the new 4 Year Support channels that were renamed. It is a re-occuring issue once/twice per year.
I understand this is a wont-fix. But can we get a better Red Hat Knowledge Base (Solution) than 3218411? Like perhaps one that tells how to clean the old repo out of the database so we can get past this bug?
The same problem again with the now called 'Update Services for SAP Solutions'. This is a repeating topic that must be fixed
This is coming up more and more, proposing for recent releases.
Actually https://bugzilla.redhat.com/show_bug.cgi?id=1570792 covers the renaming issues, moving this back.
I believe this should be closed as WONT_FIX. Here is my reasoning: 6.2: * Allows you enable a 2nd copy of a repo who's product/repo name has changed (resulting in an error that leave the system inconsistent) 6.3: * Correctly recognizes matches up an existing repo when its product/repo name has changed, showing it on the rh repos page and allowing it to be disabled. This BZ is ONLY relevant to 6.0-6.2. 6.3 is not affected by this bz. Neither 6.2 and 6.3 properly rename products or repositories though. 1). The lack of automatic renaming is being worked on as part of https://bugzilla.redhat.com/show_bug.cgi?id=1570792 and will be released as part of 6.3.z 2) To alleviate the current system inconsistency we are going to include bz1578922 in 6.2.16 if there is one. This will not fix many of the issues, but will prevent the user from putting the satellite in an inconsistent state as a result of this issue. 3) BZ1578424 contains a patch to a rake task to help cleanup 6.2.z systems in an inconsistent state. Since this issue is not present in 6.3, we are fixing the renaming issue in 6.3.z, 6.2 is near the end of its update life and we have a fix to prevent the worst effects of this issue, i propose we close this BZ.
Thank you for your interest in Satellite 6. We have evaluated this request, and we do not expect this to be implemented in the product in the foreseeable future. We are therefore closing this out as WONTFIX. If you have any concerns about this, please feel free to contact Rich Jerrido or Bryan Kearney. Thank you.
This is not a WONTFIX either. This is something that is FIXED in next release 6.4.0.
Yes, there are several versions of this bug. It will be fied in 6.4 by https://bugzilla.redhat.com/show_bug.cgi?id=1588149.