Validation fails if componentSpecs.metadata.creationTimestamp is not specified

[kparaju]

Seldon version: v0.5

If creationTimestamp is not in componentSpecs.metadata, validation fails and k8s fails to apply the changes.

kubectl failed exit status 1: The SeldonDeployment "exp-ta-sort-products" is invalid: []: Invalid value: map[string]interface  validation failure list:
(...........)
spec.predictors.componentSpecs.metadata.creationTimestamp in body must be of type string: "null"

To fix, we need to add metadata.creationTimestamp:

spec:
  name: exp-ta-sort-products
  predictors:
    - annotations:
        seldon.io/no-engine: "true"
      componentSpecs:
        - metadata:
            creationTimestamp: "2019-11-05T19:29:12Z"
          spec:
            containers:
              - env:
                  - name: API_TYPE
                    value: REST
                  - name: GUNICORN_WORKERS
                    value: "2"

[kparaju]

According to @phsiao

https://github.com/kubernetes/apimachinery/blob/master/pkg/apis/meta/v1/types.go#L196

the timestamp should be optional

[phsiao]

I think the cause is our CRD needs to be updated. The old one before the rewrite has this, and the new one likely is not defaulting

                            creationTimestamp:
                              format: date-time
                              type: string

but it is strange with this line

seldon-core/operator/api/v1alpha2/seldondeployment_webhook.go

Line 297 in 41d522f

Metadata: metav1.ObjectMeta{CreationTimestamp: metav1.Now()},

that may be incorrectly used now for unnecessary defaulting.

[ukclivecox]

The defaulting of the timestamp seems incorrect.

Do you have a simple example that recreates the issue?

[phsiao]

We were using a CRD with this line. https://github.com/SeldonIO/seldon-core/blob/v0.4.1/kustomize/seldon-core-operator/base/seldondeployments.machinelearning.seldon.io-crd.yaml#L196

So you can expect creationTime has to meet a specific format, and null does not seem to be a valid value, so I think the defaulting was the one making it work before.

New version of CRD does not have this problem, the entire MetatData is declared as an object with no specifics, so it does not have this problem.

[ukclivecox]

Maybe connected to kubernetes/kubernetes#84880

[ukclivecox]

if you could check if this works with the latest master 0.5.1-SNAPSHOT

[phsiao]

I don't think this one is related to the items (which might be relevant for #1072), rather, just older version of CRD has explicit schema for metadata, while newer version of CRD treats it as an object.

[ukclivecox]

Please reopen if still an issue