Should metav1.Time CRD generation specify nullable if the field is optional?

[vsliouniaev]

1. Create a CRD with a time field. For example ReleaseTime *metav1.Time json:"releaseTime,omitempty
2. The spec which gets generated doesn’t have releaseTime in the required section, which is as expected
3. Using k8s.io/code-generator v0.27.1 generate a client.
4. Use the Apply method to try patch the resource, clearing the releaseTime field.
5. The MarshalJson for time specifies that zero-value time will get marshalled to null
6. When the apply call is made to api the request is rejected with spec.releaseTime: Invalid value: "null": spec.releaseTime in body must be of type string: "null"
7. The solution to this appears to be to add the extra //+nullable marker to the field to get the schema to become

spec:
  properties:
    releaseTime:
      format: date-time
      nullable: true
      type: string

Seems like this should happen by default if the field is optional.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[vsliouniaev]

/remove-lifecycle rotten

[sbueringer]

Not sure if we want to start inferring additional markers based on types.

[vsliouniaev]

That's fair - thanks for the info. Feel free to close this if you feel like the behaviour is intentional.

[sbueringer]

Really not sure :), let's see if others have opinions.

(cc @vincepri @alvaroaleman)