Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1902344

Summary:	Developers unable to create application from insecure registry that is defined globally in the cluster
Product:	OpenShift Container Platform	Reporter:	Neil Girard <ngirard>
Component:	Dev Console	Assignee:	cvogt
Status:	CLOSED DUPLICATE	QA Contact:	Gajanan More <gamore>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.5	CC:	aballant, aos-bugs, cvogt, nmukherj
Target Milestone:	---	Keywords:	UpcomingSprint
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-01-18 15:10:23 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 Neil Girard 2020-11-27 22:36:34 UTC

Description of problem:
Developers are unable to enter an image from an insecure private repository that is defined in cluster images resource with pull-secrets provided in the cluster wide pull secret (pull-secret -n openshift-config).

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

How reproducible:
Always

Steps to Reproduce:
1. Create private nexus repository
2. Update the image.config.openshift.io/cluster to contain an insecure registry definition
3. Update clusterwide pull-secret to contain user/pass for the private nexus repo (oc get secret pull-secret -n openshift-config)

Actual results:
Console UI complains that the server gave HTTP response to HTTPS client.

Expected results:
Console UI allows developer to enter repository with image tag and press the Create bottom when all other fields are filled in.

Additional info:

The customer is currently working around this by having developers use cli to create their apps / deployments using yaml definitions.  They would much rather have their developers use the Developer view of the OpenShift console.

Comment 1 cvogt 2020-12-07 21:58:08 UTC

This UI uses ImageStreamImport: https://docs.openshift.com/container-platform/4.5/rest_api/image_apis/imagestreamimport-image-openshift-io-v1.html

A feature in 4.6 allows the user to check a box which will set `importPolicy: { insecure: ture }` in the ImageStreamImport. This was updated as per: https://bugzilla.redhat.com/show_bug.cgi?id=1826740 (https://github.com/openshift/console/pull/5697)

Would this solve the error?

Does `oc new-app` work with their image? If not, does it work with `--insecure-registry` ?

Comment 2 Neil Girard 2020-12-08 16:24:33 UTC

I'll check and see.  I believe they said `oc new-app` works, but they just want the developers to use the UI instead of the oc tools.  I'll mention to them that there is a new check box in 4.6 they can check to bypass that error.

On a side note, they updated their cluster to include their private repo in the image config for the cluster and was rolled out to all their nodes.  If we run podman on the nodes, it will pull the images without needed the insecure flag set.  Is there a reason the UI cannot honor this behavior as well w/o the need of a flag?  Its configured in the system as an insecure registry but not being consumed by these UI components.

Comment 3 Andrew Ballantyne 2020-12-08 17:02:28 UTC

Swapping needs info flags.

Comment 4 cvogt 2020-12-08 17:24:45 UTC

The UI uses the same `ImageStreamImport` as the oc tool.
Please confirm if indeed `oc new-app` works with or without the `--insecure-registry` flag. If the oc tool works without this flag, then we can investigate further why the UI differs.

Comment 5 Neil Girard 2020-12-08 17:47:21 UTC

Ok.  Makes sense.  Let me have them try that.  Thanks.

Comment 6 cvogt 2021-01-04 13:39:56 UTC

@ngirard can we consider this closed as it seems 4.6 works for the client?

Comment 7 Andrew Ballantyne 2021-01-11 15:28:35 UTC

@ngirard Please let us know if we can close this out based on the information already provided.

Comment 8 cvogt 2021-01-18 15:10:23 UTC


*** This bug has been marked as a duplicate of bug 1826740 ***