-
Story
-
Resolution: Unresolved
-
Minor
-
None
-
DO288 - OCP4.14-en-1-20240529
-
None
-
False
-
-
False
-
3
-
ROLE
-
-
-
en-US (English)
Please fill in the following information:
URL: | https://role.rhu.redhat.com/rol-rhu/app/courses/do288-4.14/pages/ch03s07 |
Reporter RHNID: | erich@redhat.com |
Section Title: | Lab: Building and Publishing Container Images |
Issue description:
This lab doesn't properly convey what you are hoping to convey; because the cluster is setup in such a way as to already have access to registry.ocp4.example.com:8443 by default. This is done using a global pull-secret configured by an admin for the cluster: https://docs.openshift.com/container-platform/4.14/openshift_images/managing_images/using-image-pull-secrets.html#images-update-global-pull-secret_using-image-pull-secrets
Because of this; step 3 isn't necessary; thus the task/operation is superfluous (given pull access to the registry is already provided).
Suggestion: In the `lab start` script remove the global secret (or access to the registry), and in 'lab finish' reestablish the configuration your looking for the cluster to have so that other labs function properly. This will make the need for the secret (in the namespace) more overtly clear to users, because you will/would see failures if this wasn't properly preformed.
In addition to this step 1 is ambiguous (and doesn't provide a learner with enough information to complete the task - without assistance, in my opinion). The solution provided while sufficient, may not be the way this course wan't to direct learners to take (this is an OpenShift development course after all).
A alternative solution here might be to build the container on the cluster (not locally)! Example:
- oc new-build . --to-docker=true --to registry.ocp4.example.com:8443/developer/custom-server:1.0.0
- oc start-build custom-server --from-dir .
The only issue with this approach is the poorly named; image stream that is created for our image (so step 4 is still necessary; to rename the image stream but overall still superfluous as you could just use the auto generated (albeit poorly named image stream (hello-world-nginx) in stem 5).
Steps to reproduce:
Workaround:
Expected result: