Due to a recent update on Javascript code a full page refresh on your browser might be needed.
Bug 1449225 - Need a stable location for puddles on the mirror
Summary: Need a stable location for puddles on the mirror
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Release
Version: 3.6.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 3.6.z
Assignee: Justin Pierce
QA Contact: Mike Fiedler
Depends On:
TreeView+ depends on / blocked
Reported: 2017-05-09 12:44 UTC by Mike Fiedler
Modified: 2018-01-23 17:57 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2018-01-23 17:57:29 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0113 normal SHIPPED_LIVE OpenShift Container Platform 3.7 and 3.6 bug fix and enhancement update 2018-01-23 22:55:59 UTC

Description Mike Fiedler 2017-05-09 12:44:11 UTC
Description of problem:

The location of puddles on the mirror is currently changing based on what phase of an online cycle we are in (online-int, online-stg, etc).

The QE automation needs a stable location (e.g. symlink the current active location or always push to an additional stable location).

Version-Release number of selected component (if applicable): 3.6.x

How reproducible: Always

Comment 1 Justin Pierce 2017-05-09 14:51:21 UTC
Mike -- I need some information on what you consider stable.

online-int, online-stg, and the enterprise repo have different purposes.

online-int contains builds destined for the integration cluster. Once we are happy with what is in int, we begin building stage builds into online-stg -- builds destined for the staging cluster. Eventually, the build in online-stg is promoted to online-prod (for deployment to our production clusters).

The enterprise repo kicks into gear after four sprints when we starting building enterprise release candidates (based initially on what was deployed to stage but which can completely diverge from stage thereafter). 

If you simply always want the most recent build for online, you can add online-int/latest and online-stg/latest  to your yum repos. Yum will sort out which is newer.

Comment 2 Mike Fiedler 2017-05-09 14:58:15 UTC
Stable would be something like:


We have automation that watches for new builds to be published there.   When a new build is detected, it launches Jenkins jobs to build AWS AMI and qcow2 gold images with the openshift RPMs preinstalled and all Docker images pre-pulled.

So it is more than just setting the repo URLs for yum.    

We could update the automation to watch multiple locations if needed.   Seeing if this might be a possibility first.

Comment 3 Justin Pierce 2017-05-09 15:25:02 UTC
If the desire for these gold images is just to contain ANY latest build (those that will never be released through RCM), then I would definitely suggest just monitoring online-int and online-stg. If a change is detected, one of the two will contain the latest.

If you only want to build with enterprise candidates, then:

are correct.

Comment 4 Sebastian Jug 2017-06-01 14:05:41 UTC
Is there a singular place where we can just get the *latest* version?

Comment 5 Justin Pierce 2017-06-06 12:47:32 UTC
Unfortunately, no. There are multiple independent streams now and "latest" is relative to what stream you are describing. For example, a 3.6 "online" stage build today can contain fewer fixes than a 3.6 "enterprise" build done yesterday. 
I'd recommend setting up a call to discuss if this continues to be problematic, but I don't think we have a silver bullet for you in Continuous Delivery.

Comment 7 Mike Fiedler 2017-06-08 14:26:56 UTC
How about a 3.6_all directory where we symlink every build no matter which branch.   When build completes, symlink it to 3.6_all/2017-06-10.4 .  I don't even necessarily care about latest per se.  Just having all puddles "find-able" from a stable parent repo location would be a plus.

Comment 9 Justin Pierce 2017-06-12 15:09:38 UTC
I've added a new repo which is simply "all builds" https://mirror.openshift.com/enterprise/all/3.6/ . Let me know if that helps (from today onwards).

Comment 20 errata-xmlrpc 2018-01-23 17:57:29 UTC
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.


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