Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1690250 - Update the spec.overrides field of the federatedsecret object can make the secret object created by the federatedsecret object losts data
Summary: Update the spec.overrides field of the federatedsecret object can make the se...
Keywords:
Status: ON_QA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Federation
Version: 4.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.1.0
Assignee: Maru Newby
QA Contact: Qin Ping
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-19 07:01 UTC by Qin Ping
Modified: 2019-04-15 06:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Qin Ping 2019-03-19 07:01:29 UTC
Description of problem:
Update the spec.overrides field of the federatedsecret object can make the secret object created by the federatedsecret object losts data.


Version-Release number of selected component (if applicable):
kubefed2 version: version.Info{Version:"0.0.6", GitCommit:"de6a0a909418f5ddf2d04d232b0ca55aa9cffb49", GitTreeState:"clean", BuildDate:"2019-03-14T00:43:37Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

Federation v2 controller-manager version: version.Info{Version:"0.0.6", GitCommit:"de6a0a909418f5ddf2d04d232b0ca55aa9cffb49", GitTreeState:"clean", BuildDate:"2019-03-14T00:43:37Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

$ oc get clusterversion
NAME      VERSION                             AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.0.0-0.nightly-2019-03-15-063749   True        False         3h32m   Cluster version is 4.0.0-0.nightly-2019-03-15-063749


How reproducible:
100%


Steps to Reproduce:
1. Create a federatedsecret object with the following yaml file:
$ cat federatedsecret.yaml 
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedSecret
metadata:
  name: test-secret
  namespace: default
spec:
  template:
    data:
      A: YWxhIG1hIGtvdGE=
    type: Opaque
  placement:
    clusterNames:
    - cluster1
  overrides:
  - clusterName: cluster1
    clusterOverrides:
    - path: data
      value:
        A: null
    - path: type
      value: TestSecret
secret object "test-secret" created successfully.
$ oc get secret test-secret -ojson|jq .data
{
  "A": null
}

2. Override the secret object created by the federatedsecret object with the following command:
$ oc patch federatedsecrets test-secret --type merge --patch "$(cat federatedsecrets.json)"
$ cat federatedsecrets.json 
{
    "apiVersion": "types.federation.k8s.io/v1alpha1",
    "kind": "FederatedSecret",
    "metadata": {
        "name": "test-secret",
        "namespace": "default"
    },
    "spec": {
        "overrides": [
            {
                "clusterName": "cluster1",
                "clusterOverrides": [
                    {
                        "path": "data",
                        "value": {
                            "A": null
                        }
                    },
                    {
                        "path": "type",
                        "value": "TestSecretN"  <== this is the override
                    }
                ]
            }
        ],
        "placement": {
            "clusterNames": [
                "cluster1"
            ]
        },
        "template": {
            "data": {
                "A": "YWxhIG1hIGtvdGE="
            },
            "type": "Opaque"
        }
    }
}

3. Update to the federatedsecret object reported successfully, it's an immutable field for secret API actually.
$ oc patch federatedsecrets test-secret --type merge --patch "$(cat federatedsecrets.json)"
federatedsecret.types.federation.k8s.io/test-secret patched

4. Update the federatedsecrets.json file, changed spec.overrides[0].clusterOverrides[1].value from "TestSecretN" to "TestSecret", and re-run the patch command:
oc patch federatedsecrets test-secret --type merge --patch "$(cat federatedsecrets.json)"

5. Check the secret object created by the federatedsecret object.

Actual results:
$ oc get secret test-secret -ojson|jq .data
null

It lost data.A


Expected results:
$ oc get secret test-secret -ojson|jq .data
{
  "A": null
}



Additional info:

Comment 1 Maru Newby 2019-04-03 07:20:36 UTC
(In reply to Qin Ping from comment #0)
> Description of problem:
> Update the spec.overrides field of the federatedsecret object can make the
> secret object created by the federatedsecret object losts data.

The result you are seeing appears to be kubernetes stripping out invalid data rather than federation causing data loss.  null is not a valid value in a secret map, and kubernetes itself complains if I try the following:

$ cat secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  A: null
$ kubectl create -f secret.yaml
error: error validating "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

Attempting to create a FederatedSecret with 'A: null' in the template will be similarly flagged as invalid.  It is possible to provide the value as an override, but that can only result in an empty field value in the created or updated resource, as you have reported.

Currently federated types are only validated with a crd validation schema, and that mechanism has no way of correlating override field values with the validation of their target fields.  The proposed solution is to use the dry-run validation feature added in kube 1.12 (https://github.com/kubernetes-sigs/federation-v2/issues/116).

As to attempting to change immutable fields - whether via template or override - this is a separate but also known problem (https://github.com/kubernetes-sigs/federation-v2/issues/44).  fedv2 tries to avoid providing custom behavior for a given type so as to not advantage built-in types over CRDs, but if immutable fields are not discoverable (and I don't believe they are), it may be necessary to allow configuration via FTC and set known immutable fields by default for common types.

Comment 2 Qin Ping 2019-04-03 09:26:54 UTC
I tried with oc cmd:
$ 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:"12+", GitVersion:"v1.12.4+0b75160", GitCommit:"0b75160", GitTreeState:"clean", BuildDate:"2019-04-02T01:01:15Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}

$ oc create -f secret.yaml 
secret/mysecret created

$ oc get secret mysecret -ojson
{
    "apiVersion": "v1",
    "data": {
        "A": null
    },
    "kind": "Secret",
    "metadata": {
        "creationTimestamp": "2019-04-03T09:24:45Z",
        "name": "mysecret",
        "namespace": "test",
        "resourceVersion": "521732",
        "selfLink": "/api/v1/namespaces/test/secrets/mysecret",
        "uid": "519ae245-55f2-11e9-b1f3-06887f88cca0"
    },
    "type": "Opaque"
}

So, this is why I can create a secret with data.A=null. This is not the same with kubernets

Maybe this is an issue of Openshift?

Comment 3 Qin Ping 2019-04-04 07:33:27 UTC
I filed a bug to command line interface: https://bugzilla.redhat.com/show_bug.cgi?id=1696103
When the above bug is fixed, I'll re try this one.

Comment 4 Maru Newby 2019-04-12 21:55:25 UTC
(In reply to Qin Ping from comment #3)
> I filed a bug to command line interface:
> https://bugzilla.redhat.com/show_bug.cgi?id=1696103
> When the above bug is fixed, I'll re try this one.

The above bug is fixed, moving to ON_QA.


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