Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686567 - Registry is not externally accessible
Summary: Registry is not externally accessible
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Image Registry
Version: 4.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Oleg Bulatov
QA Contact: Wenjing Zheng
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-07 17:38 UTC by Chris Callegari
Modified: 2019-03-12 14:24 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-03-11 13:25:21 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Chris Callegari 2019-03-07 17:38:01 UTC
Description of problem:
Cluster deployment completes successfully however registry is not accessible from outside of the sdn.

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

How reproducible:

Steps to Reproduce:
1. ~/bin/openshift-install --log-level debug --dir /tmp/openshift/blah create cluster | tee /tmp/openshift/blah/debug.local
2. export KUBECONFIG=/tmp/openshift/blah/auth/kubeconfig
3. kubectl get all -n openshift-image-registry
NAME                                                   READY   STATUS    RESTARTS   AGE
pod/cluster-image-registry-operator-8548dcf5b8-bttzm   1/1     Running   1          3h35m
pod/image-registry-655c654899-fnbcg                    1/1     Running   0          3h35m
pod/node-ca-4bw84                                      1/1     Running   0          3h35m
pod/node-ca-85rrb                                      1/1     Running   0          3h34m
pod/node-ca-gh9mn                                      1/1     Running   0          3h32m
pod/node-ca-pv4px                                      1/1     Running   0          3h35m
pod/node-ca-sgwb8                                      1/1     Running   0          3h35m
pod/node-ca-wzzs9                                      1/1     Running   0          3h32m

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/image-registry   ClusterIP   <none>        5000/TCP   3h35m

NAME                     DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                 AGE
daemonset.apps/node-ca   6         6         6       6            6    3h35m

NAME                                              READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/cluster-image-registry-operator   1/1     1            1           3h36m
deployment.apps/image-registry                    1/1     1            1           3h35m

NAME                                                         DESIRED   CURRENT   READY   AGE
replicaset.apps/cluster-image-registry-operator-8548dcf5b8   1         1         1       3h36m
replicaset.apps/image-registry-655c654899                    1         1         1       3h35m
replicaset.apps/image-registry-7b55dbcbb4                    0         0         0       3h35m

No routes are displayed

Actual results:

Expected results:
I expect initial cluster deployment to be complete including a general network accessible Registry.

Additional info:

Comment 1 W. Trevor King 2019-03-07 18:54:21 UTC
> 1. ~/bin/openshift-install --log-level debug --dir /tmp/openshift/blah create cluster | tee /tmp/openshift/blah/debug.local

No need for the tee, we always save debug logs in the asset directory [1].

> 3. kubectl get all -n openshift-image-registry
> ...
> No routes are displayed

Not sure about this :p.  Looks like the Route is supposed to live in the same namespace as the Deployment [2], and you see the Deployment.


Comment 2 Oleg Bulatov 2019-03-07 19:08:55 UTC
By default the registry is considered as an internal component and that it shouldn't be exposed. Still you can create routes by defining them in the operator's resource (for example, by setting spec.defaultRoute: true). Is there a reason why you need to expose the registry by default?

Comment 3 Chris Callegari 2019-03-07 19:47:42 UTC
One use case is customers that deploy multiple clusters with a single cluster and registry with direct internet access.

Comment 4 Oleg Bulatov 2019-03-08 17:27:06 UTC
So the customer has multiple clusters, but only one of them needs an external route for the registry. So most of them don't need to expose the registry, and that's the reason why we don't create routes by default.

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