interesting, the kubernetes provider wont catch sp...
# general
b
interesting, the kubernetes provider wont catch spec errors. e.g. both will “work” even though the first has
volumeMounts
and
resources
scoped wrong
Copy code
spec: {
      containers: [{
      name: coin.name,
      image: "<http://978526999579.dkr.ecr.eu-west-1.amazonaws.com/|978526999579.dkr.ecr.eu-west-1.amazonaws.com/>"+xyz.name }],
      resources: {
        requests: {
          memory: "2Gi",
          cpu: "500m"
        },
        limits: {
          memory: "4Gi",
          cpu: "1"
        }
      },
      volumeMounts: {
        name: "data", 
        mountPath: "/data"
      }
    }
Copy code
spec: {
      containers: [{
        name: coin.name,
        image: "<http://978526999579.dkr.ecr.eu-west-1.amazonaws.com/|978526999579.dkr.ecr.eu-west-1.amazonaws.com/>"+xyz.name,
        resources: {
          requests: {
            memory: "2Gi",
            cpu: "500m"
          },
          limits: {
            memory: "4Gi",
            cpu: "1"
          }
        },
        volumeMounts: [{
          name: "data",
          mountPath: "/data"
        }]
      }]
    }
m
cc @creamy-potato-29402
c
@busy-umbrella-36067 that should not be the case. Can you show me the complete object definition?
b
sure
c
I definitely get errors plugging this into a program.
b
Copy code
pod = {
    metadata: {
      labels: {
        app: xyz.name, xyz: "standard"
      },
      annotations: {
        "<http://iam.amazonaws.com/role|iam.amazonaws.com/role>": "arn:aws:iam::"+config.require("aws_account_id")+":role/xyz-"+xyz.name
      }
    },
    spec: {
      containers: [{
        name: xyz.name,
        image: "<http://978526999579.dkr.ecr.eu-west-1.amazonaws.com/|978526999579.dkr.ecr.eu-west-1.amazonaws.com/>"+xyz.name,
        resources: {
          requests: {
            memory: "2Gi",
            cpu: "500m"
          },
          limits: {
            memory: "4Gi",
            cpu: "1"
          }
        },
        volumeMounts: [{
          name: "data", 
          mountPath: "/data"
        }]
      }]
    }
  }
thats the fixed version
gets added to:
Copy code
// kubernetes statefulset resource
  manifests.push(new k8s.apps.v1.StatefulSet(name, {
    metadata: { name: xyz.name },
    spec: {
      serviceName: xyz.name,
      replicas: 2,
      updateStrategy: { type: "RollingUpdate" },
      selector: { matchLabels: pod.metadata.labels },
      template: pod,
      volumeClaimTemplates: [{
        metadata: { name: "data" },
        spec: {
          accessModes: [ "ReadWriteOnce" ],
          storageClassName: "gp2",
          resources: {
            requests: { storage: xyz.data_dir_size }
          }
        }
      }]
    }
  }))
c
@busy-umbrella-36067 can you see if this gives you an error:
Copy code
const ps: types.core.v1.PodSpec = {
    containers: [
        {
            name: appName,
            image: "<http://978526999579.dkr.ecr.eu-west-1.amazonaws.com/|978526999579.dkr.ecr.eu-west-1.amazonaws.com/>" + appName
        }
    ],
    resources: {
        requests: {
            memory: "2Gi",
            cpu: "500m"
        },
        limits: {
            memory: "4Gi",
            cpu: "1"
        }
    },
    volumeMounts: {
        name: "data",
        mountPath: "/data"
    }
}
b
reverted to the broken spec, pulumi sees it as valid. Here is a part of the diff
Copy code
~ spec    : {
                  ~ containers  : [
                      ~ [0]: {
                                image       : "<http://XXXXXXXXXXX.dkr.ecr.eu-west-1.amazonaws.com/xyz|XXXXXXXXXXX.dkr.ecr.eu-west-1.amazonaws.com/xyz>"
                                name        : "xyz"
                              - resources   : {
                                  - limits  : {
                                      - cpu   : "1"
                                      - memory: "4Gi"
                                    }
                                  - requests: {
                                      - cpu   : "500m"
                                      - memory: "2Gi"
                                    }
                                }
                              - volumeMounts: [
                              -     [0]: {
                                      - mountPath: "/data"
                                      - name     : "data"
                                    }
                                ]
                            }
                    ]
                  + resources   : {
                      + limits  : {
                          + cpu   : "1"
                          + memory: "4Gi"
                        }
                      + requests: {
                          + cpu   : "500m"
                          + memory: "2Gi"
                        }
                    }
                  + volumeMounts: {
                      + mountPath: "/data"
                      + name     : "data"
                    }
                }
            }
            updateStrategy      : {
                type: "RollingUpdate"
            }
            volumeClaimTemplates: [
                [0]: {
                    metadata: {
                        name: "data"
                    }
                    spec    : {
                        accessModes     : [
                            [0]: "ReadWriteOnce"
                        ]
                        resources       : {
                            requests: {
                                storage: "500Gi"
                            }
                        }
                        storageClassName: "gp2"
                    }
                }
            ]
        }
@creamy-potato-29402 does it have to be a const?
c
No, but I don’t see why that should matter
Just paste that code snippet in, see if it gives you a type error.
It doesn’t even have to be referenced, I just want to see if it’s a compilation error.
So on my machine, TS accepts that spec literal when I pass it to the
Deployment
constructor, and then fails to compile when I try to assign it to a
PodSpec
.
So that seems like a bug in the type checker
Can you reproduce?
b
im using JS
in a meeting atm, will get to it in a sec
c
ah
so
what is the error message you get?
b
works for me
c
Oh sorry I got confused
But
It should fail on deployment, no?
b
Copy code
~ containers  : [
                      ~ [0]: {
                                image       : ".<http://dkr.ecr.eu-west-1.amazonaws.com/|dkr.ecr.eu-west-1.amazonaws.com/>"
                              ~ name        : "" => "test"
                              - resources   : {
                                  - limits  : {
                                      - cpu   : "1"
                                      - memory: "4Gi"
                                    }
                                  - requests: {
                                      - cpu   : "500m"
                                      - memory: "2Gi"
                                    }
                                }
                              - volumeMounts: [
                              -     [0]: {
                                      - mountPath: "/data"
                                      - name     : "data"
                                    }
                                ]
                            }
                    ]
                  + resources   : {
                      + limits  : {
                          + cpu   : "1"
                          + memory: "4Gi"
                        }
                      + requests: {
                          + cpu   : "500m"
                          + memory: "2Gi"
                        }
                    }
                  + volumeMounts: {
                      + mountPath: "/data"
                      + name     : "data"
                    }
                }
            }
c
Right, I’m saying, it should fail when you try to run the update, right?
b
nope
Copy code
info: 3 changes performed:
    ~ 3 resources updated
      4 resources unchanged
Update duration: 3.210246876s

Permalink: <https://app.pulumi.com/XXXXX>
c
So this resource successfully deploys to Kubernetes?
b
yes
c
what the heck.
can you
kubectl get -o yaml
Kubernetes ACCEPTS that??
that’s wild.
b
yeah it just doesnt have the item
it doesnt accept it when you try to add it in via edit
c
I’m kind of dumbstruck.
b
same
c
Can you run
kubectl version
b
Client Version: version.Info{Major:“1”, Minor:“10", GitVersion:“v1.10.0”, GitCommit:“fc32d2f3698e36b93322a3465f63a14e9f0eaead”, GitTreeState:“clean”, BuildDate“2018 03 26T1655:54Z”, GoVersion:“go1.9.3”, Compiler:“gc”, Platform:“darwin/amd64”} Server Version: version.Info{Major:“1", Minor:“10+“, GitVersion:“v1.10.3-eks”, GitCommit:“58c199a59046dbf0a13a387d3491a39213be53df”, GitTreeState:“clean”, BuildDate“2018 09 21T2100:04Z”, GoVersion:“go1.9.3”, Compiler:“gc”, Platform:“linux/amd64”};
maybe its due to the way im creating the object?
Copy code
exports.getManifest = function(name, items, config) {
  manifests = []
  item = getItems(name, items)

  testSpec = k8s.core.v1.PodSpec = {
...

 // kubernetes statefulset resource
  manifests.push(new k8s.apps.v1.StatefulSet(name, {

...

  return manifests
}
theres a k8s service that gets added to
manifests
as well
c
So a couple of weird things
(1) The Pulumi TS types don’t catch this (2) The Kubernetes API server does not appear to catch this (3) Yet somehow https://kubeyaml.com/ does.
@busy-umbrella-36067 could you file a bug in pulumi-kubernetes? Something is up and we should find out what that is.
b
sure
c
I’ll supplement your report with my own results, and then we’ll go from there.
b
@creamy-potato-29402 let me know if i should add more https://github.com/pulumi/pulumi-kubernetes/issues/232