Bug 712049

Summary: Repo ids for protected custom repos shouldn't be like "custom-10000"
Product: Red Hat Update Infrastructure for Cloud Providers Reporter: Sachin Ghai <sghai>
Component: ToolsAssignee: Jay Dobies <jason.dobies>
Status: CLOSED NOTABUG QA Contact: wes hayutin <whayutin>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 2.0CC: kbidarka, sghai, tsanders
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-06-09 13:20:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Sachin Ghai 2011-06-09 11:13:37 UTC
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:

Comment 1 Sachin Ghai 2011-06-09 11:14:58 UTC
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

Comment 2 Jay Dobies 2011-06-09 13:20:00 UTC
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-****".