Bug 669365 - [RFE] Need to additionally sync listings files from CDN for $arch and $basever substitution
Summary: [RFE] Need to additionally sync listings files from CDN for $arch and $baseve...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Update Infrastructure for Cloud Providers
Classification: Red Hat
Component: RHUA
Version: 1.2
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
: ---
Assignee: Jay Dobies
QA Contact: wes hayutin
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-13 13:59 UTC by Todd Sanders
Modified: 2011-05-09 17:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-09 17:54:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Todd Sanders 2011-01-13 13:59:19 UTC
In RHUI 1.2, we changed from having a configuration file with the list
of channels to reading them dynamically from the content certificate
(the one that Red Hat provides, or in this scenario, the entitlement
certificate that comes from the master).

That presented a problem. Most of the URLs contain variable
substitutions for things like arch and version. For example:

content/dist/rhel/rhui/server/$releasever/$basearch/rhui/1.1/os

We can't use that URL directly to query CDN. The RHUA needs to use not
only valid values for $releasever and $basearch, but all valid values.
In other words, the RHUA needs to download both i386 and x86_64 for
$basearch.

After some investigation, the best approach is to store a file on CDN
that contains the possible values for each of those two variables. The
RHUA then breaks down the URL and does the lookups.

For instance, when the RHUA encounters $releasever in the URL above, it
chops that part off of the URL and looks for a listing file in the same
directory. That's not just a cute name, it's actually called listing. So
in the above example, it'd look for:

content/dist/rhel/rhui/server/listing

That file is a plain-text file containing values for $releasever that we
should use. It's contents are simply:

5Server

Then we encounter the next variable, $basearch. For each value in the
previous listing file, we do another lookup:

content/dist/rhel/rhui/server/5Server/listing

That one is a bit more interesting. That file contains:

i386
x86_64

Putting all of that together, we came out with two repos to sync:

content/dist/rhel/rhui/server/5Server/i386/
content/dist/rhel/rhui/server/5Server/x86_64/

So, this brings us back to our master-slave solution. It's currently
failing because the content certificates still have variable
substitutions in them but those listing files don't exist on the master CDS.

I'd suggest we just add them manually to the master CDS. The other
approach would be to generate a custom entitlement certificate that
doesn't use variables, but I think adding the listing files should be
easier. Let me know if it's not clear where they go or their contents
and we'll go from there.

Comment 1 Jay Dobies 2011-05-09 17:54:45 UTC
No longer relevant in RHUI 2.x.


Note You need to log in before you can comment on or make changes to this bug.