Zero value fields should not be printed

[wlan0]

On conversion and reversion, the Zero value fields with values like "null" or replicas: 0 should not be printed.

This was from my conversion from kube to koki first and then back.

- apiVersion: extensions/v1beta1
  kind: ReplicaSet
  metadata:
    creationTimestamp: null
    name: frontend
  spec:
    replicas: 3
    template:
      metadata:
        creationTimestamp: null
        labels:
          app: guestbook
          tier: frontend
      spec:
        containers:
        - env:
          - name: GET_HOSTS_FROM
            value: dns
          image: gcr.io/google_samples/gb-frontend:v3
          name: php-redis
          ports:
          - containerPort: 80
            protocol: TCP
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
  status:
    replicas: 0

status should'nt have shown similarly, creationTimeStamp key should'nt have shown in the output

[ublubu]

We don't control serialization of kubernetes api types. ReplicaSetStatus.Replicas doesn't have omitempty set so that's why the zero appears. You'll see similar things across the board if you just deserialize and reserialize a k8s api object.

CreationTimestamp uses metav1.Time, which has custom serialization code that specifically uses the string "null", so that would require upstream changes as well.

[wlan0]

I know how the kubernetes types work.

You are setting the value to an uninitialized but allocated object

Status has an omitempty (https://github.com/kubernetes/api/blob/master/extensions/v1beta1/types.go#L802), and won't show up if you leave replicas as nil. When you set the replicas to an empty object, the Status object loses its Zero value status and shows up making my file look ugly.

[ublubu]

https://github.com/kubernetes/api/blob/master/extensions/v1beta1/types.go#L853 Status.Replicas isn't a pointer, though.

[wlan0]

You're right - Is there no way to omit that field when the Status is zero valued?

[ublubu]

I believe so. I think that part is outside our control.

[wlan0]

we can access the text section of the go program and change (should mprotect PROT_WRITE for the appropriate pages in the runtime) the compiled type signature in the running go program to do this. I have a working example.

Would not recommend doing this though.

[wlan0]

Closing because the replicas issue was solved by using pointers - ezpz