Description of problem: If to create the custom repo, the ID is required to be unique. There is no such requirement for a repo path. If the path of a new repo duplicates the path of the existing repo, the unknown error is reported and a traceback is displayed in logs. Version-Release number of selected component (if applicable): >> rpm -qa "*rhui*" rh-amazon-rhui-client-rhs30-2.2.124-1.el7.noarch rhui-installer-base-0.0.24-1.el7ui.noarch rh-rhui-tools-libs-pre.3.0.16-1.el7ui.noarch rhui-installer-0.0.24-1.el7ui.noarch rh-rhui-tools-pre.3.0.16-1.el7ui.noarch rhui-default-ca-1.0-1.noarch rh-amazon-rhui-client-2.2.118-1.el7.noarch RHUI iso 20151013 How reproducible: always Steps to Reproduce: Create one custom repo and then create the second custom repo with the same 'path at which the repository will be served' like for the first repo. From home screen: 1 'r' - manage repositories 2. 'c' - create a new custom repository (RPM content only) >>rhui (repo) => c >>Unique ID for the custom repository (alphanumerics, _, and - only): custom-i386-x86_64 >>Display name for the custom repository [custom-i386-x86_64]: [ENTER] >>Path at which the repository will be served [custom-i386-x86_64]: custom/i386/x86_64 >> Algorithm to use when calculating the checksum values for repository metadata: >>* Select "sha256" for RHEL6: >>* Select "sha1" for either RHEL5 or RHEL6: >> 1 - sha256 >> 2 - sha1 >> Enter value (1-2) or 'b' to abort: 1 >> Should the repository require an entitlement certificate to access? (y/n) y >> Based on the repository's relative path, the suggested entitlement path is: custom/i386/x86_64 >> Path that should be used when granting an entitlement for this repository. This may use yum variable substitutions (e.g. $basearch) to group this together with other repositories that share the entitlement [custom/i386/x86_64]: [ENTER] >> Should the repository require clients to perform a GPG check and verify packages are signed by a GPG key? (y/n) n >> The following repository will be created: >> ID: custom-i386-x86_64 >> Name: custom-i386-x86_64 >> Path: custom/i386/x86_64 >> Entitlement: custom/i386/x86_64 >> GPG Check No >> Red Hat GPG Key: No >> Proceed? (y/n) y Successfully created repository custom-i386-x86_64 ------------------------------------------------------------------------------ rhui (repo) => c >>Unique ID for the custom repository (alphanumerics, _, and - only): custom-x86_64-x86_64 >>Display name for the custom repository [custom-x86_64-x86_64]: [ENTER] >>Path at which the repository will be served [custom-x86_64-x86_64]: custom/i386/x86_64 >>Algorithm to use when calculating the checksum values for repository metadata: >>* Select "sha256" for RHEL6: >>* Select "sha1" for either RHEL5 or RHEL6: >> >> 1 - sha256 >> 2 - sha1 >>Enter value (1-2) or 'b' to abort: 1 >> Should the repository require an entitlement certificate to access? (y/n) y >> Based on the repository's relative path, the suggested entitlement path is: custom/i386/x86_64 >> Path that should be used when granting an entitlement for this repository. This may use yum variable substitutions (e.g. $basearch) to group this together with other repositories that share the entitlement [custom/i386/x86_64]: [ENTER] >> Should the repository require clients to perform a GPG check and verify packages are signed by a GPG key? (y/n) n >> The following repository will be created: >> ID: custom-x86_64-x86_64 >> Name: custom-x86_64-x86_64 >> Path: custom/i386/x86_64 >> Entitlement: custom/i386/x86_64 >> GPG Check No >> Red Hat GPG Key: No >> Proceed? (y/n) y An unexpected error has occurred during the last operation. More information can be found in /root/.rhui/rhui.log. >> less /root/.rhui/rhui.log 2016-01-29 06:16:01,560 - <class 'pulp.bindings.exceptions.BadRequestException'> 2016-01-29 06:16:01,560 - Unexpected error caught at the shell level Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/rhui/tools/shell.py", line 88, in safe_listen self.listen(clear=first_run) File "/usr/lib/python2.7/site-packages/rhui/tools/shell.py", line 122, in listen Shell.listen(self) File "/usr/lib/python2.7/site-packages/rhui/common/shell.py", line 186, in listen item.func(*args, **item.kwargs) File "/usr/lib/python2.7/site-packages/rhui/tools/screens/repo.py", line 520, in create_custom rh_gpg_key) File "/usr/lib/python2.7/site-packages/rhui/tools/pulp_api.py", line 783, in create_custom_repo distributors) File "/usr/lib/python2.7/site-packages/pulp/bindings/repository.py", line 81, in create_and_configure return self.server.POST(path, repo_data) File "/usr/lib/python2.7/site-packages/pulp/bindings/server.py", line 98, in POST log_request_body=log_request_body) File "/usr/lib/python2.7/site-packages/pulp/bindings/server.py", line 161, in _request self._handle_exceptions(response_code, response_body) File "/usr/lib/python2.7/site-packages/pulp/bindings/server.py", line 202, in _handle_exceptions raise code_class_mappings[response_code](response_body) BadRequestException: RequestException: POST request on /pulp/api/v2/repositories/ failed with 400 - Relative URL [custom/i386/x86_64] for repository [custom-x86_64-x86_64] conflicts with existing relative URL [custom/i386/x86_64] for repository [custom-i386-x86_64] Expected results: During repo creation dialogue 1. Change "Path at which the repository will be served" for "Unique path at which the repository will be served" 2. If the user specifies the repo path which duplicates already existing one, through a message "Relative URL [$url] for repository [$new_repo] conflicts with existing relative URL [$url] for repository [$existing_repo]" and allow the user to enter a different path and continue 3. No traceback in logs, just an error message
may be dupe of https://bugzilla.redhat.com/show_bug.cgi?id=1325333
*** Bug 1325333 has been marked as a duplicate of this bug. ***
On RHEL6 and 7 ISO's 20161025 rhui (repo) => l Custom Repositories unprotected_repo1 unprotected_repo2_sha1 Red Hat Repositories Red Hat Update Infrastructure 2.0 (RPMs) (6Server-i386) Red Hat Update Infrastructure 2.0 (RPMs) (6Server-x86_64) ------------------------------------------------------------------------------ rhui (repo) => c Unique ID for the custom repository (alphanumerics, _, and - only): unprotected_repo1_duplicate Display name for the custom repository [unprotected_repo1_duplicate]: Path at which the repository will be served [unprotected_repo1_duplicate]: unprotected_repo1 Algorithm to use when calculating the checksum values for repository metadata: 1 - sha256 (default) 2 - sha1 (RHEL 5) Enter value (1-2) or 'b' to abort: 1 Should the repository require an entitlement certificate to access? (y/n) n Should the repository require clients to perform a GPG check and verify packages are signed by a GPG key? (y/n) n The following repository will be created: ID: unprotected_repo1_duplicate Name: unprotected_repo1_duplicate Path: unprotected_repo1 GPG Check No Red Hat GPG Key: No Proceed? (y/n) y Error creating repository: Failed to create the unprotected_repo1_duplicate repository for the following reason: HTTP 400 Relative URL [unprotected/unprotected_repo1] for repository [unprotected_repo1_duplicate] conflicts with existing relative URL [unprotected/unprotected_repo1] for repository [unprotected_repo1]. Questions: 1. Why is not the uniqueness of the url path checked as soon as a user enters path and presses [ENTER], but only when all other repo options (GPG check and key) are prompted? E.g. the repo ID uniqueness is checked immediately: Unique ID for the custom repository (alphanumerics, _, and - only): unprotected_repo1 A repository with ID "unprotected_repo1" already exists Unique ID for the custom repository (alphanumerics, _, and - only): 2. Why was not "Path at which the repository will be served [unprotected_repo1_duplicate]:" changed with "Unique path at which the repository will be served [unprotected_repo1_duplicate]:" as similar to "Unique ID for the custom repository"?
1. There is no pulp API to check if the url path is duplicated, so currently we only know it's a duplicate when we try to create it. The alternative is to pull every repository in rhui and iterate through all of them, which is time consuming. I propose that we make a new feature for this and put it in the backlog. 2. This is a good suggestion, I'll update the wording
On ISO 20161109 wording update: 'Unique path at which the repository will be served [custom_repo1]:'
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:0367