Error parsing unquoted timestamp in ConfigGroup

[hazsetata]

Trying to add a YAML file as ConfigGroup like this:

let linkerdCG = new k8s.yaml.ConfigGroup("linkerd-cg",
    {
        files: "t.yaml",
    },
    {
        providers: {
            kubernetes: kubernetesCluster.kubernetesProvider
        },
        dependsOn: [ kubernetesCluster.kubernetesProvider ]
    }
);

with t.yaml's content being:

---
kind: Namespace
apiVersion: v1
metadata:
  name: linkerd
  annotations:
    linkerd.io/inject: disabled
---
kind: Secret
apiVersion: v1
metadata:
  name: linkerd-identity-issuer
  namespace: linkerd
  labels:
    linkerd.io/control-plane-component: identity
  annotations:
    linkerd.io/created-by: linkerd/cli edge-19.3.3
    linkerd.io/identity-issuer-expiry: 2020-03-25T13:37:11Z
data:
  crt.pem: ZXhhbXBsZQ==
  key.pem: dmFsdWU=

results in an error:

error: Plan apply failed: Secret in version "v1" cannot be handled as a Secret: v1.Secret.ObjectMeta: v1.ObjectMeta.Annotations: ReadString: expects " or n, but found {, error found in #10 byte of ...|-expiry":{}},"labels|..., bigger context ...|edge-19.3.3","linkerd.io/identity-issuer-expiry":{}},"labels":{"app.kubernetes.io/managed-by":"pulum|...

kubectl apply -f t.yaml succeeds, also if the date at the error position is double-quoted ("2020-03-25T13:37:11Z") it succeeds.

[hausdorff]

Thanks for the report! This seems like a bug in either their our our YAML parser. I do wonder how many problems like this there are... cc @lblackstone

[hausdorff]

I think we should serialize all values in annotations as a string, because that is the type the Kubernetes OpenAPI spec asks for.

The sequence of events that happens right now is: this gets parsed by js-yaml correctly into a Date, which then gets sent to the Secret constructor, which happily sends it to the Kubernetes provider serialized this not as a string but as an empty gRPC struct. client-go sees this empty struct and happily ignores it.

[hausdorff]

Actually, looking at the Kubernetes data structures in client-go, it seems like they only have json: tags on their fields -- so an even simpler solution is to just use the JSON datatype schema for deserialization.