HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
openshift
origin
Go2015–2020
openshift / origin

origin

Conformance test suite for OpenShift

17Distinct people
23Mentions
0Explicit recommenders
8.7KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Conformance test suite for OpenShift

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:56:55 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year23 dated mentions

Observed mentions: 2015-01-29 07:49:04 UTC to 2020-07-08 19:12:29 UTC.

0123452015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 2 submissions, 1 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC321
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC505
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC514
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC505
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Origin Kubernetes This repo was previously the core Kubernetes tracking repo for OKD, and where OpenShift's hyperkube and openshift-test binaries were maintained. As of July 2020, the purpose and maintenance strategy of the repo varies by branch. Maintenance of main and release-x.x branches for 4.6 and above These branches no longer include the code required to produce hyperkube binaries, and are limited to maintaining the openshift-tests binary. Responsibility for maintaining hyperkube has transitioned to the openshift/kubernetes repo. Backports and carries against upstream should be proposed to openshift/kubernetes. If changes merged to openshift/kubernetes need to land in origin, it will be necessary to follow up with a PR to origin that bumps the vendoring. Branch names are correlated across the 2 repositories such that changes merged to a given branch in openshift/kubernetes should be vendored into the same branch in origin (e.g. master in openshift/kubernetes is vendored into main in origin). NOTE: Vendoring of the main and release-x.x branches of openshift/kubernetes into the equivalent branches in origin is intended to be temporary. At some point in the near future, origin will switch to vendoring origin-specific branches (e.g origin-4.6-kubernetes-1.19.2) to minimize the scope of backports and carries that need to be considered in the context of openshift/kubernetes rebases. Test exclusion rules Test exclusion is now handled through environmental selector based filtering rather than test annotations. Environmental selectors allow tests to be filtered or skipped based on the cluster environment and configuration. For example, selectors can be defined that match kube e2e tests that are known to be incompatible with specific OpenShift configurations and exclude those tests from running. Maintenance of test exclusion rules is split between the openshift/kubernetes and origin repos to ensure that PRs proposed to openshift/kubernetes can be validated against the set of kube e2e tests known to be compatible with OpenShift. Test exclusion rules for kubernetes e2e tests are maintained in: https://github.com/openshift/kubernetes/blob/master/openshift-hack/cmd/k8s-tests-ext: environment_selectors.go disabled_tests.go Test exclusion rules for openshift e2e tests are maintained in: https://github.com/openshift/origin/blob/main/pkg/test/extensions: environment_selectors.go disabled_tests.go To update test exclusion rules for kube e2e tests, update the environmental selectors in openshift/kubernetes. For OpenShift e2e tests, update the selectors in origin. Vendoring from openshift/kubernetes These origin branches vendor k8s.io/kubernetes and some of its staging repos (e.g. k8s.io/api) from our openshift/kubernetes fork. Upstream staging repos are used where possible, but some tests depends on functionality that is only present in the fork. When a change has merged to an openshift/kubernetes branch that needs to be vendored into the same branch in origin, the hack/update-kube-vendor.sh helper script simplifies updating the go module configuration for all dependencies sourced from openshift/kubernetes for that branch. The script requires either the name of a branch or a SHA from openshift/kubernetes: $ hack/update-kube-vendor.sh <openshift/kubernetes branch name or SHA> The script also supports performing a fake bump to validate an as-yet unmerged change to openshift/kubernetes. This can be accomplished by supplying the name of a fork repo as the second argument to the script: $ hack/update-kube-vendor.sh <branch name or SHA> github.com/myname/kubernetes Once the script has executed, the vendoring changes will need to be committed and proposed to the repo. Working around '410 Gone' error If the script returns '410 Gone' as per the error that follows, it may be that the golang checksum server does not yet know about the target SHA. go: k8s.io/kubernetes@v1.21.1 (replaced by github.com/openshift/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003): verifying go.mod: g ithub.com/openshift/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003/go.mod: reading https://sum.golang.org/lookup/github.com/openshif t/kubernetes@v1.21.2-0.20210603185452-2dfc46b23003: 410 Gone server response: not found: The workaround is to set GOSUMDB=off to disable the checksum database for the vendoring update: $ GOSUMDB=off hack/update-kube-vendor.sh <branch name or SHA> Maintenance of release-4.5, release-4.4 and release-4.3 Releases prior to 4.6 continue to maintain hyperkube in the origin repo in the release-4.x branches. Persistent carries and backports for those branches should continue to be submitted directly to origin. openshift/kubernetes is not involved except for rebases. End-to-End (e2e) and Extended Tests End to end tests (e2e) should verify a long set of flows in the product as a user would see them. Two e2e tests should not overlap more than 10% of function and are not intended to test error conditions in detail. The project examples should be driven by e2e tests. e2e tests can also test external components working together. All e2e tests are compiled into the openshift-tests binary. To build the test binary, run make. To run a specific test, or an entire suite of tests, read test/extended/README for more information. Updating external examples hack/update-external-example.sh will pull down example files from external repositories and deposit them under the examples directory. Run this script if you need to refresh an example file, or add a new one. See the script and examples/quickstarts/README.md for more details.
Read the full README on GitHub

What Hacker News says

5 sources
OpenStack (IaaS) != OpenShift (PaaS) Getting up and running with OpenShift is pretty easy. You can either use the all in one Vagrant VM[1] or you can download the CLI[2] and run `oc cluster up`[3] to install the docker container version. Either one doesn't give you an "HA" install (probably want a cluster for that). I regularly deliver OpenShift installs, and in most enterprise environments an HA install takes 3-4 weeks, most of which is communicating to all the silos (networking, storage, security, virtualization, etc) what the requirements are. Disclaimer: I work for Red Hat. 1: https://www.openshift.org/vm/ 2: https://github.com/openshift/origin/releases 3: https://github.com/openshift/origin/blob/master/docs/cluster...
In Walmart Will Manage Distribution Centers with OneOps, Jenkins, and Kubernetes
Disclaimer: I work for Red Hat on OpenShift v3, an open-source enterprise-ready distribution of Kubernetes. We have solved #2 by deploying an internal docker registry [1], push to it once a build succeeds, and automatically (or not) trigger deployments once an expected image lands in it [2]. In the future we will support webhooks so you can trigger deployments from external registries such as quay.io or DockerHub. You can have a look at the all-in-one VM we have: git clone https://github.com/openshift/origin cd origin vagrant up vagrant ssh oc cluster up The last command will spin up a cluster with a docker registry, a HTTP router, and a bunch of images for you to play around with. https://asciinema.org/a/49402 [1] The same underlying registry thay powers DockerHub: https://github.com/docker/distribution [2] A Kubernetes controller loop t
Read the rest
hat watches for new images and triggers new deployments.
In Why Kubernetes is winning the container war
Disclaimer: I work at Red Hat on OpenShift. All of the code Red Hat contributed around Kubernetes storage plugins went into Kubernetes upstream. If you have any questions or problems, feel free to raise an issue or reach out to us in the community. Red Hat has a large number of contributors on the Kubernetes project and we are big fans of the community and the technology! Red Hat OpenShift provides a an enterprise-ready Kubernetes distribution that also builds on top of Docker, RHEL/Fedora/CentOS and includes integrated networking (OVS), routing (HAProxy), logging (ELK stack), metrics, image registry, automated image builds & deployments, integrated CI/CD (Jenkins), and self-service UX (Web, CLI, IDE). You can check out the free Origin community distro here - https://github.com/openshift/origin or sign up for our free hosted developer pr
Read the rest
eview here: https://www.openshift.com/devpreview/. We also offer commercially supported solutions - https://www.openshift.com/container-platform/.
In Why Kubernetes is winning the container war

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.