Bug 1390139

Related PR: https://github.com/openshift/origin/pull/11664

Please ignore the PR linked to in https://bugzilla.redhat.com/show_bug.cgi?id=1390139#c1

Actual related PR: https://github.com/openshift/origin/pull/11733

xiaocwan After applying the patch in the linked PR, the command in step 3 returns the error:

> error: resource(s) were provided, but no name, label selector, or --all flag specified

To avoid this, I have to specify the name of the resource whose container image I wish to change:

```
# oc set image rc dctest-1 dctest-1=xiaocwan-r/ho:latest --local -o yaml
```

In the command above, `dctest-1` ends up being the name of the specific replication controller I wish to target. I believe this error was not happening in the command mentioned under "Additional info" because prior to the patch in the PR, running a command locally always ignored any "resource arguments" that were passed, it always attempted to use a resource from a file, even if a filename was not specified by a user. With the patch, this command should now give the error:

```
# oc set image rc dctest-1=xiaocwan-r/ho:latest --local -o yaml -f rc.yaml

error: when paths, URLs, or stdin is provided as input, you may not specify resource arguments as well
```

Related bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1388404

Upstream PR (https://github.com/kubernetes/kubernetes/pull/36071) has merged. Origin PR (https://github.com/openshift/origin/pull/11733) will merge after the kube 1.6 rebase

Adjusting tags to fit the "waiting for upstream rebase" state.

Origin PR (https://github.com/openshift/origin/pull/11733) has merged, moving to ON_QA

Sorry but this Origin PR (https://github.com/openshift/origin/pull/11733) is closed and it hasn't been merged.

Tested on latest OCP openshift/oc v3.6.94 but still reproduces this issue, is there any PR directly for OCP?

(In reply to XiaochuanWang from comment #8)
> Sorry but this Origin PR (https://github.com/openshift/origin/pull/11733) is
> closed and it hasn't been merged.
> 
> Tested on latest OCP openshift/oc v3.6.94 but still reproduces this issue,
> is there any PR directly for OCP?

Changes should be on latest master. Not sure about OCP, but updated PR for this was merged here: https://github.com/openshift/origin/pull/14123

Moving to MODIFIED to wait for the next OCP build.

The output is still the same with original "Actual result" even specify the rc name, but as per Comment 2 's expected, it needs an explanation error message "error: when paths, URLs, or stdin is provided as input, you may not specify resource arguments as well"

Tested on oc v3.6.133
kubernetes v1.6.1+5115d708d7

Now the output is:
# oc set image rc dctest-1 dctest-1=xiaocwan-r/ho:latest --local -o yaml 
error: You must provide one or more resources by argument or filename.
Example resource specifications include:
   '-f rsrc.yaml'
   '--filename=rsrc.json'
   'pods my-pod'
   'services'

I'm going to mark this one UpcomingRelease so that we can discuss about it, since I believe there's something conceptually wrong with the command. 

When running a command like 'set image' with TYPE or TYPE/NAME I need to go get the resource data on the server, *specially* if I want to display the resource entirely with -o yaml. How is that supposed to work with --local, which never goes to the server?

--local is supposed to work fine when the resource is --filename, but by resource type and name we either fail with an error message right away, or try to get it from the cache if not yet expired, otherwise fail.

I would expect --local to be incompatible with "<type> <name>" or "<type>/<name>" usage and to error immediately

Related upstream PR: https://github.com/kubernetes/kubernetes/pull/48763

With linked patch, specifying a resource by `<resource>/<name>` pair with a `--local` flag now results in the error:

# oc set image dc/idling-echo idling-tcp-echo=ruby:2.0 --local -o yaml
error: you must specify resources by --filename when --local is set.
Example resource specifications include:
   '-f rsrc.yaml'
   '--filename=rsrc.json'

Specifying both a `<resource>/<name>` pair and a resource by filename (or stdin), still results in the error:

# oc set image -f examples/image-streams/image-streams-centos7.json dc/idling-echo idling-tcp-echo=ruby:2.0  -o yaml
error: resource/name arguments cannot be provided when a path is specified

Related origin PR: https://github.com/openshift/origin/pull/15140

Marking as "UpcomingRelease"; Upstream PR changes [1] will be brought in as part of the next rebase.

1. https://github.com/kubernetes/kubernetes/pull/48763

Upstream PR [1] has merged.
Tagging as UpcomingRelease

1. https://github.com/kubernetes/kubernetes/pull/48763

This will be fixed in 3.9, the fix is coming with the upstream rebase that lands there.

Tested with oc/OCP v3.9.0-0.21.0.
Negative tests:
$ oc set image # Below prompt is acceptable
error: You must provide one or more resources by argument or filename.
Example resource specifications include:
   '-f rsrc.yaml'
   '--filename=rsrc.json'
   '<resource> <name>'
   '<resource>'

$ oc set image dc/dctest dctest-1=openshift/hello-openshift --local -o yaml # Below prompt is acceptable
error: you must specify resources by --filename when --local is set.
Example resource specifications include:
   '-f rsrc.yaml'
   '--filename=rsrc.json'

Postive tests:
$ oc set image -f dc-with-two-containers.yaml dctest-1=openshift/hello-openshift --local -o yaml # Can get correct YAML content
apiVersion: v1
kind: DeploymentConfig
metadata:
<snipped>
    spec:
      containers:
      - image: openshift/hello-openshift
        name: dctest-1
<snipped>

So bug is fixed. Because PR targets "any of the kube set ... sub-commands", BTW checked `oc set resources` with above cmd format, got similar result