Skip to content

Commit 4f02579

Browse files
authored
Adding support for hardcoded redhat registry (registry.redhat.io) (#50)
* Adding support for hardcoded redhat registry (registry.redhat.io) * doc update
1 parent c645109 commit 4f02579

File tree

4 files changed

+6
-5
lines changed

4 files changed

+6
-5
lines changed

Makefile

+1-1
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,7 @@ coverage-html: test
5757
go tool cover -html cover.out
5858

5959
update-certified-catalog:
60-
./tnf fetch --operator --container --helm
60+
./oct fetch --operator --container --helm
6161

6262
# Update source dependencies and fix versions
6363
update-deps:

README.md

+3-1
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,9 @@ This is a Work in Progress PoC/demo project, not a complete/GA nor a ready to us
77
# Motivation
88
## Completely disconnected environments issue
99

10-
Tipically, partners run the TNF container in a "bastion" host or whatever Linux machine with access to the OCP nodes. In case that machine does not have internet access for security or any other reasons, TNF will run in a fully/completely disconnected environment. That's not a problem for TNF, except for one test suite: `affiliated-certification`. The test cases on that test suite will check the certification status of the CNF's containers, operators and/or helm charts releases. To do so, it relies on two mechanisms: first, these test cases will try to reach the Red Hat's online catalog, which is just a regular HTTP rest service that can be accessed from anywhere, anytime. In case this service is not reachable, which will happen in a completely disconnected environment, the test case falls back to an "offline" check mechanism, which involves querying the TNF's embedded catalog. So, if the TNF release is too old, those test cases could fail, as the RH's catalog for certified artifacts is continuosly updated, with a lot of new entries being added, modified or removed every day.
10+
Typically, partners run the TNF container in a "bastion" host or whatever Linux machine with access to the OCP nodes. In case that machine does not have internet access for security or any other reasons, TNF will run in a fully/completely disconnected environment. That's not a problem for TNF, except for one test suite: `affiliated-certification`. The test cases on that test suite will check the certification status of the CNF's containers, operators and/or helm charts releases. To do so, it relies on two mechanisms: first, these test cases will try to reach the Red Hat's online catalog, which is just a regular HTTP rest service that can be accessed from anywhere, anytime. In case this service is not reachable, which will happen in a completely disconnected environment, the test case falls back to an "offline" check mechanism, which involves querying the TNF's embedded catalog. So, if the TNF release is too old, those test cases could fail, as the RH's catalog for certified artifacts is continuously updated, with a lot of new entries being added, modified or removed every day.
11+
12+
Note: Only partner certified images are stored in the offline database. If Redhat images are checked against the offline database, they will show up as not certified. The online database includes both Partner and Redhat images.
1113

1214
If a partner is using the latest official TNF release, let's say v4.1, it will come with an embedded offline catalog that was downloaded and embedded at the same moment the v4.1 version was released. For each day that passes, that offline catalog will be more and more outdated, but the partners will be using that v4.1 until v4.2 comes out, which could take months. If they upgrade their CNFs with new operators/containers that have been added recently to the online catalog, the TNF certification test cases will fail.
1315

certdb/offlinecheck/container.go

+1-2
Original file line numberDiff line numberDiff line change
@@ -43,8 +43,7 @@ type ContainerCatalogEntry struct {
4343
ID string `json:"_id"`
4444
Architecture string `json:"architecture"`
4545
Certified bool `json:"certified"`
46-
DockerImageDigest string `json:"docker_image_digest"`
47-
DockerImageID string `json:"docker_image_id"` // image digest
46+
DockerImageDigest string `json:"image_id"`
4847
Repositories []Repository `json:"repositories"`
4948
}
5049
type ContainerPageCatalog struct {

cmd/tnf/fetch/fetch.go

+1-1
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ import (
1616

1717
var (
1818
// containersCatalogSizeURL = "https://catalog.redhat.com/api/containers/v1/images?filter=certified==true&page=0&include=total,page_size"
19-
containersCatalogPageURL = "https://catalog.redhat.com/api/containers/v1/images?filter=certified==true&page_size=%d&page=%d&include=data.repositories,data.docker_image_digest,data.architecture"
19+
containersCatalogPageURL = "https://catalog.redhat.com/api/containers/v1/images?filter=certified==true&page_size=%d&page=%d&include=data.repositories,data.image_id,data.architecture"
2020
operatorsCatalogSizeURL = "https://catalog.redhat.com/api/containers/v1/operators/bundles?filter=organization==certified-operators"
2121
operatorsCatalogPageURL = "https://catalog.redhat.com/api/containers/v1/operators/bundles?filter=organization==certified-operators&page_size=%d&page=%d"
2222
helmCatalogURL = "https://charts.openshift.io/index.yaml"

0 commit comments

Comments
 (0)