Bug 2074237 - oc new-app --image-stream flag behavior is unclear
Summary: oc new-app --image-stream flag behavior is unclear
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Build
Version: 4.11
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.11.0
Assignee: jawed
QA Contact: Jitendar Singh
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-04-11 20:18 UTC by Ben Parees
Modified: 2023-09-15 01:53 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-08-10 11:05:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift oc pull 1119 0 None open Bug 2074237: clarify use of --image-stream for oc new-app 2022-04-28 13:17:14 UTC
Red Hat Product Errata RHSA-2022:5069 0 None None None 2022-08-10 11:06:44 UTC

Description Ben Parees 2022-04-11 20:18:50 UTC
Description of problem:
oc new-app https://github.com/sclorg/nodejs-ex --image-stream=cli:latest

does not do the right thing.

If you look at the resources produced from this invocation, the "cli:latest" imagestream is only used as a trigger for the app deployment.

cli:latest should be used as the builder image for the github repo.

Instead, new-app still inspects the repo, detects it as a nodejs app, and attempts to use the nodejs builder imagestream.  Meaning you can't force new-app to use "cli:latest" as the builder image instead.

so it's not clear what --image-stream is actually doing in this invocation.

passing --image has similarly strange behavior, all it does is add an imagestream pointing to the image in question, but it doesn't consume the image/imagestream for building the app.

The only way to actually specify the builder image to use, is to use this syntax:

oc new-app someimage~https://github.com/sclorg/nodejs-ex

where someimage can be either an imagestream or an image.


If the intent isn't that the value passed to --image-stream be used as the builder image for the repo being provided, then at least we need to clarify in the help just what the argument is used for.  It doesn't seem to do much, at least when you're using new-app to construct buildconfigs.  Perhaps when using it to just deploy an app based on an existing imagestream it makes more sense.



Version-Release number of selected component (if applicable):
v4.11 but probably older too

How reproducible:
always

Actual results:
--image-stream argument isn't really used by the resulting artifacts

Expected results:
either it's used, or the help text makes it clearer what the behavior is intended to be.  Same for --image.

Comment 2 jawed 2022-04-28 13:17:04 UTC
I confirm the argument is only used to deploy an app from an existing image, Images can come from image streams in the cluster, images from specific registry
hence my PR to clarify use of --image-stream for oc new-app

Comment 3 Ben Parees 2022-04-28 13:27:15 UTC
thanks, that help text clarification looks good to me.

Comment 6 Priti Kumari 2022-05-10 12:54:47 UTC
Verified

=========================


$ oc new-app -h
[...]
--image=[]: Name of a container image to include in the app.  Note:  not specifying a registry or repository means
defaults in place for client image pulls are employed.
  -i, --image-stream=[]: Name of an existing image stream to use to deploy an app.

Comment 8 errata-xmlrpc 2022-08-10 11:05:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5069

Comment 9 Red Hat Bugzilla 2023-09-15 01:53:50 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days


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