Bug 1696103

Summary: oc command has some issues for secret API when secret object has some data is nil
Product: OpenShift Container Platform Reporter: Qin Ping <piqin>
Component: ocAssignee: Maciej Szulik <maszulik>
Status: CLOSED DEFERRED QA Contact: Xingxing Xia <xxia>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.1.0CC: aos-bugs, erich, jokerman, maszulik, mfojtik, mmccomas
Target Milestone: ---   
Target Release: 4.4.0   
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: 2020-01-31 11:16:29 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 Qin Ping 2019-04-04 07:31:24 UTC
Description of problem:
When a secret has a nil data, oc create command gets a different result from kubectl and gets a different result from oc patch command.

Version-Release number of selected component (if applicable):
$ oc version
Client Version: version.Info{Major:"4", Minor:"0+", GitVersion:"v4.0.22", GitCommit:"d14915559e", GitTreeState:"", BuildDate:"2019-03-14T21:55:38Z", GoVersion:"", Compiler:"", Platform:""}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+73cc796", GitCommit:"73cc796", GitTreeState:"clean", BuildDate:"2019-04-03T19:18:59Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.4+73cc796", GitCommit:"73cc796", GitTreeState:"clean", BuildDate:"2019-04-03T19:18:59Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}


How reproducible:
100%

Steps to Reproduce:
1. Create a secret with oc command
$ oc create -f secret.yaml 
secret/mysecret created
$ cat secret.yaml 
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  A: null
2. Check the secret
$ oc get secret mysecret -ojson| jq .data.A
""
3. Patch the secret
$ oc patch secret mysecret -p '{"data": {"A": null}}'
secret/mysecret patched
$ oc get secret mysecret -ojson| jq .data
null
$ oc get secret mysecret -ojson
{
    "apiVersion": "v1",
    "kind": "Secret",
    "metadata": {
        "creationTimestamp": "2019-04-04T07:08:49Z",
        "name": "mysecret",
        "namespace": "default",
        "resourceVersion": "100741",
        "selfLink": "/api/v1/namespaces/default/secrets/mysecret",
        "uid": "7ec3ab45-56a8-11e9-8d97-0242fc54bf62"
    },
    "type": "Opaque"
}
secret.data lost.
4. Create the secret with kubectl
$ kubectl create -f ~/secret.yaml 
error: error validating "/home/qinping/secret.yaml": error validating data: unknown object type "nil" in Secret.data.A; if you choose to ignore these errors, turn validation off with --validate=false

Actual results:
There are some different for the process of secret with nil data.

Expected results:
Process secret with nil data as kubectl.

Additional info:

Comment 1 Maciej Szulik 2019-04-05 20:01:41 UTC
Fix in https://github.com/openshift/origin/pull/22497

Comment 2 Maciej Szulik 2019-04-15 09:42:13 UTC
The fix from previous comment was not merged, we'll be looking into alternative solutions. This is not a 4.1 blocker, so I'm moving this one over to 4.2.

Comment 3 Maciej Szulik 2019-08-08 10:58:32 UTC
The underling issue is that we don't enable openapi validation due to its incompleteness, I'm moving this to 4.3 for now.

Comment 4 Eric Rich 2019-09-05 19:14:59 UTC
(In reply to Maciej Szulik from comment #2)
> The fix from previous comment was not merged, we'll be looking into
> alternative solutions. This is not a 4.1 blocker, so I'm moving this one
> over to 4.2.

Where is this other work being tracked/discussed (the aforementioned PR was closed)?

Comment 5 Maciej Szulik 2019-09-10 08:47:39 UTC
> Where is this other work being tracked/discussed (the aforementioned PR was closed)?

We need to close the work on openapi v3 which is part of api&auth team backlog. Only then,
with complete schema we will be able to properly address this problem.

Comment 6 Maciej Szulik 2020-01-31 11:16:29 UTC
This was converted to a jira task https://issues.redhat.com/browse/WRKLDS-133