Hide Forgot
Description of problem: When we create a client config rpm and passes the entitlement certs of protected custom repos, it creates the mirror files of protected custom repos like: rh-custom-1000.mirror rh-custom-1001.mirror And for unprotected custom repos, the mirror files are named as: rh-repo101.mirror <-- uses user-deined name (repo101) So unprotected custom repos used the user defined repo name, however protected custom repos uses naming convention like "custom-10001" Version-Release number of selected component (if applicable): pulp 0.186 rhui-tools 2.0.26 How reproducible: always Steps to Reproduce: 1. Create client config rpms using protected custom repo entitlements Actual results: [root@dhcp193-100 rhel-client-config-4.0]# cd tmp/rhel-client-config-4.0/ [root@dhcp193-100 rhel-client-config-4.0]# ls ca.crt key.pem rh-custom-10000.mirror rh-rhel5_unprotected.mirror content.crt rh-cloud.repo rh-custom-10001.mirror [root@dhcp193-100 rhel-client-config-4.0]# cat rh-cloud.repo [custom-10000] name=Custom Repositories - 10000 mirrorlist=file:///etc/yum.repos.d/rh-custom-10000.mirror enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify=1 sslclientkey=/etc/pki/entitlement/key.pem sslclientcert=/etc/pki/entitlement/product/content.crt sslcacert=/etc/pki/entitlement/ca.crt Expected results: Repo IDs should be user-defined IDs Additional info:
Example: Here defined ID is "rhel5_protected", however the rh-cloud.repo uses the [custom-10000] Defined ID: rhel5_protected ================================ The following repository will be created: ID: rhel5_protected Name: rhel5_protected Path: /protected/rhel5 Entitlement: /protected/rhel5 Proceed? (y/n) y Selected custom repos: ======================= Select one or more repositories to include in the entitlement certificate: (an * next to a Red Hat repository indicates it is deployed in the RHUI) Custom Repositories x 1 : /protected/rhel5 rhel5_protected x 2 : /protected/repo101/ repo101 ----------------------------- [root@dhcp193-100 client]# cd rhel-client-config-4.0/ [root@dhcp193-100 rhel-client-config-4.0]# ls build tmp [root@dhcp193-100 rhel-client-config-4.0]# cd tmp/rhel-client-config-4.0/ [root@dhcp193-100 rhel-client-config-4.0]# ls ca.crt key.pem rh-custom-10000.mirror rh-rhel5_unprotected.mirror content.crt rh-cloud.repo rh-custom-10001.mirror [root@dhcp193-100 rhel-client-config-4.0]# cat rh-cloud.repo [custom-10000] <-- here repo ID should be "rhel5_protected" name=Custom Repositories - 10000 mirrorlist=file:///etc/yum.repos.d/rh-custom-10000.mirror enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify=1 sslclientkey=/etc/pki/entitlement/key.pem sslclientcert=/etc/pki/entitlement/product/content.crt sslcacert=/etc/pki/entitlement/ca.crt
This is intentional, but will require some explanation. Unprotected repos are simple. The repo definition points to the repo itself. Done. That's why we're able to easily use the ID as the repo definition ID. For protected repos, the repo definition is actually derived from the entitlement, not the repo itself. So for a repo: /foo/i386/os We suggest they use an entitlement of: /foo/$basearch/os Tha rationale there is that they will likely also be creating: /foo/x86_64/os The $basearch entitlement will cover both cases, depending on where's it's installed. This is actually immensely helpful to the cloud provider. This way, they can produce a single client config RPM that gets installed on both i386 and x86_64 images. Getting back to the question at hand, the repo definition is derived from the entitlement, not the repo. So the repo definition will be for the $basearch URL. The problem is that that maps back to multiple repos inside of the RHUA (both the i386 and x86_64 ones). So it's not as simple as taking the repo ID, since the yum repo definition may correspond to multiple RHUI repos. I decided to just use a unique number to get past the yum requirement for unique repo IDs. That way I don't have to attempt to generate some ID from potentially multiple repos. Does that make sense? Given that, I'm closing this as not a bug, since this was an intentional decision. That said, I'm open to suggestions if you can think of something better than "custom-****".