Bug 1449225
| Summary: | Need a stable location for puddles on the mirror | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Mike Fiedler <mifiedle> |
| Component: | Release | Assignee: | Justin Pierce <jupierce> |
| Status: | CLOSED ERRATA | QA Contact: | Mike Fiedler <mifiedle> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.6.0 | CC: | aos-bugs, jialiu, jokerman, mmccomas, sejug, tdawson, wabouham, wmeng |
| Target Milestone: | --- | ||
| Target Release: | 3.6.z | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: |
undefined
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-01-23 17:57:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mike Fiedler
2017-05-09 12:44:11 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. Stable would be something like: https://mirror.openshift.com/enterprise/enterprise-3.5/latest/RH7-RHAOS-3.5/x86_64/os/ 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. 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: https://mirror.openshift.com/enterprise/enterprise-3.5/latest/x86_64/os/ https://mirror.openshift.com/enterprise/enterprise-3.6/latest/x86_64/os/ ...etc are correct. Is there a singular place where we can just get the *latest* version? 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. 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. 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). 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-2018:0113 |