Field deletion doesn't work well in SSA

[mengqiy]

k8s version is 1.19.1.

I first created the following by using kubectl apply --server-side -f backendconfig.yaml

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: bar
  namespace: default
spec:
  connectionDraining:
    drainingTimeoutSec: 30
  securityPolicy:
    name: bol-default-policy

The following is what has been created and persisted:

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  creationTimestamp: "2020-09-11T18:18:40Z"
  generation: 1
  managedFields:
  - apiVersion: cloud.google.com/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:connectionDraining:
          f:drainingTimeoutSec: {}
        f:securityPolicy:
          f:name: {}
    manager: kubectl
    operation: Apply
    time: "2020-09-11T18:18:40Z"
  name: bar
  namespace: default
  resourceVersion: "214762"
  selfLink: /apis/cloud.google.com/v1/namespaces/default/backendconfigs/bar
  uid: 8d90b477-994f-4091-b631-95f19ad10730
spec:
  connectionDraining:
    drainingTimeoutSec: 30
  securityPolicy:
    name: bol-default-policy

Then I tried to re-apply the following using kubectl apply --server-side -f backendconfig.yaml

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: bar
  namespace: default
spec:
  # <=========== connectionDraining field is removed.
  securityPolicy:
    name: bol-default-policy

I got error:

The BackendConfig "bar" is invalid: spec.connectionDraining: Invalid value: "null": spec.connectionDraining in body must be of type object: "null"

I also tried to re-apply the following using kubectl apply --server-side -f backendconfig.yaml

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: bar
  namespace: default
spec:
  connectionDraining: null  # <======= connectionDraining is set to null
  securityPolicy:
    name: bol-default-policy

I got the same error:

The BackendConfig "bar" is invalid: spec.connectionDraining: Invalid value: "null": spec.connectionDraining in body must be of type object: "null"

On the other hand, I tried to update the created object with kubectl replace -f backendconfig.yaml

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: bar
  namespace: default
spec:
  connectionDraining: null  # <======= connectionDraining is set to null
  securityPolicy:
    name: bol-default-policy

I got the same schema validation error as SSA above.

But if I run kubectl replace with the following, it can successfully remove the field w/o error.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: bar
  namespace: default
spec:
  # <========== connectionDraining field is removed.
  securityPolicy:
    name: bol-default-policy

I have played with SMD v4 libary a bit, my understanding is that:
SMD v4 set the field as null in the merged object when it infers the user want to delete the field.
In this case, initially it is

spec:
  connectionDraining:
    drainingTimeoutSec: 30
  securityPolicy:
    name: bol-default-policy

Then I SSA:

spec:
  securityPolicy:
    name: bol-default-policy

In the apiserver, SMD v4 merged the object as the following before the object goes to the validation:

spec:
  connectionDraining: null
  securityPolicy:
    name: bol-default-policy

The OpenAPI schema validation rejects the object since the connectionDraining field is an object:

              connectionDraining:
                description: ConnectionDrainingConfig contains configuration for connection
                  draining. For now the draining timeout. May manage more settings
                  in the future.
                properties:
                  drainingTimeoutSec:
                    description: Draining timeout in seconds.
                    format: int64
                    type: integer
                type: object

[mengqiy]

It seems builtin types doesn't have the same problem.

[apelisse]

/wg api-expression

[jpbetz]

/assign

[mengqiy]

Please provide an update when you have figured out a plan to solve this. Thanks!

In case you need the full schema of the BackendConfig CRD, you can find it on any GKE clusters or GCE clusters (cluster/kube-up.sh).

[jpbetz]

@mengqiy Hoping to get some time to look more close at this early next week.

[mengqiy]

A simpler CRD to reproduce in k8s 1.19 server:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: microservices.infra.example.org
spec:
  group: infra.example.org
  names:
    kind: MicroService
    listKind: MicroServiceList
    plural: microservices
    singular: microservice
  scope: Namespaced
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        description: This is the Schema for the MicroService API
        properties:
          apiVersion:
            description: 'APIVersion defines the versioned schema of this representation
                  of an object. Servers should convert recognized schemas to the latest
                  internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
            type: string
          kind:
            description: 'Kind is a string value representing the REST resource this
                  object represents. Servers may infer this from the endpoint the client
                  submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
            type: string
          metadata:
            type: object
          spec:
            description: Specification defines the desired state of MicroService
            properties:
              exampleField:
                description: This is an example field.
                type: string
              anotherField:
                description: This is another example field.
                type: string
              embededField:
                description: This is an embeded field.
                properties:
                  foo:
                    description: foo field
                    type: string
                type: object
            type: object
          status:
            description: Status of the API
            properties:
              ready:
                description: ready or not ?
                type: string
            type: object
        type: object
    subresources:
      status: { }

SSA an instance of the CR:

kubectl apply --server-side -f crd-instance.yaml

apiVersion: infra.example.org/v1
kind: MicroService
metadata:
  namespace: default
  name: foo
spec:
  exampleField: foo
  embededField:
    foo: bar

Re-SSA the CR with a field removed:

$ kubectl apply --server-side -f crd-instance.yaml
The MicroService "foo" is invalid: spec.embededField: Invalid value: "null": spec.embededField in body must be of type object: "null"

apiVersion: infra.example.org/v1
kind: MicroService
metadata:
  namespace: default
  name: foo
spec:
  exampleField: foo

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[apelisse]

/remove-lifecycle stale

[captainroy-hy]

come across the same problem, it only happens to CR and built-in types work well.
k8s version: 1.19.1