make it possible to override test image

Describe the feature you would like and why you want it
I want to avoid this issue:
k describe pod daemonset-daemonset-1602943254-1602943260-phkg2 |tail -5
  Warning  Failed          4m27s (x3 over 6m40s)   kubelet            Failed to pull image "gcr.io/google-containers/pause:3.1": rpc error: code = Unknown desc = Get https://gcr.io/v1/_ping: dial tcp <IP_ADDRESS>:443: i/o timeout
  Warning  Failed          4m27s (x3 over 6m40s)   kubelet            Error: ErrImagePull
  Normal   BackOff         3m51s (x7 over 6m39s)   kubelet            Back-off pulling image "gcr.io/google-containers/pause:3.1"
  Normal   Pulling         3m40s (x4 over 7m26s)   kubelet            pulling image "gcr.io/google-containers/pause:3.1"
  Warning  Failed          2m13s (x10 over 6m39s)  kubelet            Error: ImagePullBackOff

i.e. be possible to override which pause-image to use.
Additional context
values in use:
apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
  name: kuberhealthy
  namespace: kuberhealthy
spec:
  releaseName: kuberhealthy
  resetValues: true
  helmVersion: v3
  chart:
    repository: https://comcast.github.io/kuberhealthy/helm-repos
    name: kuberhealthy
    version: 2.2.0
  values:
    image:
      repository: fsdepot.evry.com:8085/kuberhealthy/kuberhealthy
    prometheus:
      enabled: true
    deployment:
      nodeSelector:
        fs.evry.com/finods-group: aot
      args:
      - -dsPauseContainerImageOverride
      - fsdepot.evry.com:8085/google_containers/pause:3.1
    podSecurityPolicy:
      enabled: true
    check:
      daemonset:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/daemonset-check
      deployment:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/deployment-check
      dnsInternal:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/dns-resolution-check
      dnsExternal:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/dns-resolution-check
      podRestarts:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/pod-restarts-check
      podStatus:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/pod-status-check
      networkConnection:
        image:
          repository: fsdepot.evry.com:8085/kuberhealthy/network-connection-check
    checkReaper:
      enabled: false
      image:
        repository: fsdepot.evry.com:8085/kuberhealthy/check-reaper

OK, found out how to override via search the slack-channel in k8s:
extraEnvs:
+          PAUSE_CONTAINER_IMAGE: "fsnexus.evry.com:8085/google-containers/pause:3.1"

but it still fails on:
Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  15s               default-scheduler  Successfully assigned kuberhealthy/deployment-deployment-c94964c49-74f24 to alt-eos-g-kwo03
  Normal   Pulled     0s (x3 over 14s)  kubelet            Container image "nginx:1.17.8" already present on machine
  Warning  Failed     0s (x3 over 14s)  kubelet            Error: container has runAsNonRoot and image will run as root

hi @davidkarlsen
which version of the daemonset-check do you use?
this is a snipped which runs in our environment
    securityContext:
      runAsNonRoot: false
      runAsUser: 0
    containers:
      - env:
          - name: POD_NAMESPACE
            value: "caas-system"
          - name: CHECK_POD_TIMEOUT
            value: "10m"
          - name: PAUSE_CONTAINER_IMAGE
            value: "company.registry/caas/pause:3.2"
        image: company.registry/caas/kuberhealthy-daemonset-check:v2.2.2
        name: kuberhealthy-daemonset

log-output of the kuberhealthy-check-daemonset pod:
time="2020-10-19T05:00:48Z" level=info msg="Found instance namespace: caas-system"
time="2020-10-19T05:00:48Z" level=info msg="Kuberhealthy is located in the caas-system namespace."
time="2020-10-19T05:00:50Z" level=info msg="Deleting any rogue daemonsets or daemonset pods before deploying the daemonset check"
time="2020-10-19T05:00:51Z" level=info msg="Timeout set to 10m0s"
time="2020-10-19T05:00:51Z" level=info msg="Waiting for all rogue daemonsets or daemonset pods to clean up"
time="2020-10-19T05:00:51Z" level=info msg="waiting for all daemonsets to clear"
time="2020-10-19T05:00:56Z" level=info msg="all daemonsets cleared"
time="2020-10-19T05:00:56Z" level=info msg="No rogue daemonsets or daemonset pods exist."
time="2020-10-19T05:00:56Z" level=info msg="Setting DS pause container override image to:reg-company.registry/caas/pause:3.2"
time="2020-10-19T05:00:56Z" level=info msg="Enabling daemonset checker"
time="2020-10-19T05:00:56Z" level=info msg="runAsUser will be set to %v 1000"
time="2020-10-19T05:00:57Z" level=info msg="Searching for unique taints on the cluster."

Using chart version 2.2.0:
apiVersion: comcast.github.io/v1
kind: KuberhealthyCheck
metadata:
  creationTimestamp: "2020-10-17T12:41:47Z"
  generation: 2
  name: daemonset
  namespace: kuberhealthy
  resourceVersion: "263646891"
  selfLink: /apis/comcast.github.io/v1/namespaces/kuberhealthy/khchecks/daemonset
  uid: 1ecb85f9-1076-11eb-afa7-005056b81f42
spec:
  podSpec:
    containers:
    - env:
      - name: POD_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: CHECK_POD_TIMEOUT
        value: 10m
      - name: PAUSE_CONTAINER_IMAGE
        value: fsnexus.evry.com:8085/google-containers/pause:3.1
      image: fsdepot.evry.com:8085/kuberhealthy/daemonset-check:v2.2.2
      imagePullPolicy: IfNotPresent
      name: main
      resources:
        requests:
          cpu: 10m
          memory: 50Mi
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
    securityContext:
      fsGroup: 999
      runAsUser: 999
    serviceAccountName: daemonset-khcheck
  runInterval: 15m
  timeout: 12m

could you please paste the output of kubectl logs of the kuberhealthy-daemonset-check pods log?

k logs daemonset-1603094214|tail -30
time="2020-10-19T07:57:21Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-7nffh on node ilt-aot-g-kmg01"
time="2020-10-19T07:57:21Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-8ktrl on node alt-ebs-g-kwo01"
time="2020-10-19T07:57:21Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-bzhf8 on node ald-dts-g-kwo02"
time="2020-10-19T07:57:21Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-mbzb5 on node ald-dts-g-kwo01"
time="2020-10-19T07:57:21Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-mvzp7 on node alt-eos-g-kwo02"
time="2020-10-19T07:57:21Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-nvnqn on node ilt-aot-g-kpx02"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603094214-1603094220,source=kuberhealthy,khcheck=daemonset"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker Daemonset check waiting for 5 pods to delete"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-7nffh on node ilt-aot-g-kmg01"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-8ktrl on node alt-ebs-g-kwo01"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-bzhf8 on node ald-dts-g-kwo02"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-mbzb5 on node ald-dts-g-kwo01"
time="2020-10-19T07:57:22Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-mvzp7 on node alt-eos-g-kwo02"
time="2020-10-19T07:57:23Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603094214-1603094220,source=kuberhealthy,khcheck=daemonset"
time="2020-10-19T07:57:23Z" level=info msg="DaemonSetChecker Daemonset check waiting for 4 pods to delete"
time="2020-10-19T07:57:23Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-7nffh on node ilt-aot-g-kmg01"
time="2020-10-19T07:57:23Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-8ktrl on node alt-ebs-g-kwo01"
time="2020-10-19T07:57:23Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-bzhf8 on node ald-dts-g-kwo02"
time="2020-10-19T07:57:23Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-mbzb5 on node ald-dts-g-kwo01"
time="2020-10-19T07:57:24Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603094214-1603094220,source=kuberhealthy,khcheck=daemonset"
time="2020-10-19T07:57:24Z" level=info msg="DaemonSetChecker Daemonset check waiting for 1 pods to delete"
time="2020-10-19T07:57:24Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-7nffh on node ilt-aot-g-kmg01"
time="2020-10-19T07:57:25Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603094214-1603094220,source=kuberhealthy,khcheck=daemonset"
time="2020-10-19T07:57:25Z" level=info msg="DaemonSetChecker Daemonset check waiting for 1 pods to delete"
time="2020-10-19T07:57:25Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603094214-1603094220-7nffh on node ilt-aot-g-kmg01"
time="2020-10-19T07:57:26Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603094214-1603094220,source=kuberhealthy,khcheck=daemonset"
time="2020-10-19T07:57:26Z" level=info msg="DaemonSetChecker Daemonset check waiting for 0 pods to delete"
time="2020-10-19T07:57:26Z" level=info msg="DaemonSetChecker Test daemonset has finished removing pods"
time="2020-10-19T07:57:26Z" level=info msg="Error reporting success to Kuberhealthy servers: bad POST request to kuberhealthy status reporting url: Post http://kuberhealthy.kuberhealthy.svc.cluster.local/externalCheckStatus: dial tcp: lookup kuberhealthy.kuberhealthy.svc.cluster.local on <IP_ADDRESS>:53: no such host"
time="2020-10-19T07:57:26Z" level=error msg="Error running check: DaemonSetChecker in namespace kuberhealthy: bad POST request to kuberhealthy status reporting url: Post http://kuberhealthy.kuberhealthy.svc.cluster.local/externalCheckStatus: dial tcp: lookup kuberhealthy.kuberhealthy.svc.cluster.local on <IP_ADDRESS>:53: no such host"

also: how can I changed the endpoint to post status to? We have a slightly different dns suffix

i'm more interested on following loglines (appears on container-start)
...
time="2020-10-19T05:00:56Z" level=info msg="all daemonsets cleared"
time="2020-10-19T05:00:56Z" level=info msg="No rogue daemonsets or daemonset pods exist."
time="2020-10-19T05:00:56Z" level=info msg="Setting DS pause container override image to:reg-company.registry/caas/pause:3.2"
time="2020-10-19T05:00:56Z" level=info msg="Enabling daemonset checker"
...

also: how can I changed the endpoint to post status to? We have a slightly different dns postfix

this could be done via the ENV-Var: KH_EXTERNAL_REPORTING_URL - repo-search

@davidkarlsen could you please also share the generated daemonset- or pod-spec to get a better understanding, what exactly k8s tries do do?
together with logmessage from the DaemonSetChecker-pod we will find a solution ;-)

pod:
apiVersion: v1
kind: Pod
metadata:
  annotations:
    comcast.github.io/check-name: daemonset
    kubernetes.io/psp: ibm-restricted-psp
    seccomp.security.alpha.kubernetes.io/pod: docker/default
  creationTimestamp: "2020-10-21T21:00:24Z"
  labels:
    app: kuberhealthy-check
    kuberhealthy-check-name: daemonset
    kuberhealthy-run-id: 873062f1-3e4c-4167-a05c-6a527529ae37
  name: daemonset-1603314019
  namespace: kuberhealthy
  ownerReferences:
  - apiVersion: v1
    kind: Pod
    name: kuberhealthy-86cf79df9f-9tsbs
    uid: 4233141e-13de-11eb-afa7-005056b81f42
  resourceVersion: "267029007"
  selfLink: /api/v1/namespaces/kuberhealthy/pods/daemonset-1603314019
  uid: 70b32637-13e0-11eb-afa7-005056b81f42
spec:
  containers:
  - env:
    - name: POD_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    - name: CHECK_POD_TIMEOUT
      value: 10m
    - name: PAUSE_CONTAINER_IMAGE
      value: fsnexus.evry.com:8085/google-containers/pause:3.1
    - name: KH_REPORTING_URL
      value: http://kuberhealthy.kuberhealthy.svc.icp-global.local
    - name: KH_RUN_UUID
      value: 873062f1-3e4c-4167-a05c-6a527529ae37
    - name: KH_CHECK_RUN_DEADLINE
      value: "1603314739"
    - name: KH_POD_NAMESPACE
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.namespace
    image: fsdepot.evry.com:8085/kuberhealthy/daemonset-check:v2.2.2
    imagePullPolicy: IfNotPresent
    name: main
    resources:
      requests:
        cpu: 10m
        memory: 50Mi
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: daemonset-khcheck-token-sfttj
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: alt-ebs-g-kwo01
  priority: 0
  restartPolicy: Never
  schedulerName: default-scheduler
  securityContext:
    fsGroup: 999
    runAsUser: 999
    supplementalGroups:
    - 1
  serviceAccount: daemonset-khcheck
  serviceAccountName: daemonset-khcheck
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: daemonset-khcheck-token-sfttj
    secret:
      defaultMode: 420
      secretName: daemonset-khcheck-token-sfttj
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-10-21T21:00:24Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2020-10-21T21:00:52Z"
    message: 'containers with unready status: [main]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2020-10-21T21:00:52Z"
    message: 'containers with unready status: [main]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2020-10-21T21:00:24Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://1a08e3795969146586fc63d16c36746478689426b0da043ebe067d2a3bac437e
    image: fsdepot.evry.com:8085/kuberhealthy/daemonset-check:v2.2.2
    imageID: docker-pullable://fsdepot.evry.com:8085/kuberhealthy/daemonset-check@sha256:52b854c4061cbe93cf6771441b3bddabaf9470e1e7165676f60dea423da5602c
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: docker://1a08e3795969146586fc63d16c36746478689426b0da043ebe067d2a3bac437e
        exitCode: 1
        finishedAt: "2020-10-21T21:00:51Z"
        reason: Error
        startedAt: "2020-10-21T21:00:25Z"
  hostIP: <IP_ADDRESS>
  phase: Failed
  podIP: <IP_ADDRESS>
  qosClass: Burstable
  startTime: "2020-10-21T21:00:24Z"

log:
time="2020-10-21T21:00:25Z" level=info msg="Found instance namespace: kuberhealthy"
time="2020-10-21T21:00:25Z" level=info msg="Kuberhealthy is located in the kuberhealthy namespace."
time="2020-10-21T21:00:25Z" level=info msg="Deleting any rogue daemonsets or daemonset pods before deploying the daemonset check"
time="2020-10-21T21:00:25Z" level=info msg="Timeout set to 10m0s"
time="2020-10-21T21:00:25Z" level=info msg="Waiting for all rogue daemonsets or daemonset pods to clean up"
time="2020-10-21T21:00:25Z" level=info msg="waiting for all daemonsets to clear"
time="2020-10-21T21:00:30Z" level=info msg="all daemonsets cleared"
time="2020-10-21T21:00:30Z" level=info msg="No rogue daemonsets or daemonset pods exist."
time="2020-10-21T21:00:30Z" level=info msg="Setting DS pause container override image to:fsnexus.evry.com:8085/google-containers/pause:3.1"
time="2020-10-21T21:00:30Z" level=info msg="Enabling daemonset checker"
time="2020-10-21T21:00:30Z" level=info msg="runAsUser will be set to %v 999"
time="2020-10-21T21:00:30Z" level=info msg="Searching for unique taints on the cluster."
time="2020-10-21T21:00:30Z" level=info msg="Found taints to tolerate: [{dedicated  dts NoSchedule <nil>} {dedicated  infra NoSchedule <nil>}]"
time="2020-10-21T21:00:30Z" level=info msg="Generating daemon set kubernetes spec."
time="2020-10-21T21:00:30Z" level=info msg="Deploying daemon set with tolerations:  []"
time="2020-10-21T21:00:31Z" level=info msg="DaemonSetChecker Daemonset check waiting for 18 pods to come up on nodes [ilt-aot-g-kma02 alt-eos-g-kwo01 ilt-lbx-g-kpx01 ilt-aot-g-kpx02 ald-dts-g-kwo03 alt-aot-g-kwo01 alt-aot-g-kwo02 alt-eos-g-kwo02 alt-eos-g-kwo03 alt-eos-g-kwo04 ald-dts-g-kwo02 alt-ebs-g-kwo01 ilt-aot-g-kma01 ilt-aot-g-kma03 ilt-aot-g-kmg01 ilt-aot-g-kpx01 ilt-lbx-g-kpx02 ald-dts-g-kwo01]"
time="2020-10-21T21:00:32Z" level=info msg="DaemonSetChecker Daemonset check waiting for 1 pods to come up on nodes [alt-eos-g-kwo03]"
time="2020-10-21T21:00:33Z" level=info msg="All daemonset pods have been ready for 1 / 5 seconds."
time="2020-10-21T21:00:34Z" level=info msg="All daemonset pods have been ready for 2 / 5 seconds."
time="2020-10-21T21:00:36Z" level=info msg="All daemonset pods have been ready for 3 / 5 seconds."
time="2020-10-21T21:00:37Z" level=info msg="All daemonset pods have been ready for 4 / 5 seconds."
time="2020-10-21T21:00:38Z" level=info msg="All daemonset pods have been ready for 5 / 5 seconds."
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Daemonset daemonset-daemonset-1603314019-1603314025 done deploying pods."
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker removing 18 daemonset pods"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker removing daemonset"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker removing daemonset pods"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Daemonset check waiting for 18 pods to delete"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2hsrd on node alt-eos-g-kwo03"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-5qzqx on node ilt-aot-g-kma03"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-6j52g on node ald-dts-g-kwo03"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-6q5bg on node alt-aot-g-kwo02"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-dmkdw on node ilt-aot-g-kma01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-dzj7w on node alt-ebs-g-kwo01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-kdcwz on node alt-eos-g-kwo02"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-l46wj on node ald-dts-g-kwo01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-llnfp on node ald-dts-g-kwo02"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:38Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-xtvbv on node ilt-aot-g-kpx02"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Daemonset check waiting for 18 pods to delete"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2hsrd on node alt-eos-g-kwo03"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-5qzqx on node ilt-aot-g-kma03"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-6j52g on node ald-dts-g-kwo03"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-6q5bg on node alt-aot-g-kwo02"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-dmkdw on node ilt-aot-g-kma01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-dzj7w on node alt-ebs-g-kwo01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-kdcwz on node alt-eos-g-kwo02"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-l46wj on node ald-dts-g-kwo01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-llnfp on node ald-dts-g-kwo02"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:39Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-xtvbv on node ilt-aot-g-kpx02"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Daemonset check waiting for 9 pods to delete"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-kdcwz on node alt-eos-g-kwo02"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:40Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Daemonset check waiting for 9 pods to delete"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-kdcwz on node alt-eos-g-kwo02"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:41Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Daemonset check waiting for 8 pods to delete"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:42Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Daemonset check waiting for 8 pods to delete"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:43Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Daemonset check waiting for 8 pods to delete"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:44Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Daemonset check waiting for 8 pods to delete"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-frtqc on node ilt-aot-g-kpx01"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:45Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Daemonset check waiting for 7 pods to delete"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-2mbgn on node ilt-aot-g-kma02"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-98l99 on node alt-eos-g-kwo04"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-tjvdq on node ilt-aot-g-kmg01"
time="2020-10-21T21:00:46Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:47Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:47Z" level=info msg="DaemonSetChecker Daemonset check waiting for 4 pods to delete"
time="2020-10-21T21:00:47Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-297x4 on node ilt-lbx-g-kpx02"
time="2020-10-21T21:00:47Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:47Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:47Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:48Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:48Z" level=info msg="DaemonSetChecker Daemonset check waiting for 3 pods to delete"
time="2020-10-21T21:00:48Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-bjcc7 on node alt-eos-g-kwo01"
time="2020-10-21T21:00:48Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:48Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:49Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:49Z" level=info msg="DaemonSetChecker Daemonset check waiting for 2 pods to delete"
time="2020-10-21T21:00:49Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-qx8sr on node alt-aot-g-kwo01"
time="2020-10-21T21:00:49Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:50Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:50Z" level=info msg="DaemonSetChecker Daemonset check waiting for 1 pods to delete"
time="2020-10-21T21:00:50Z" level=info msg="DaemonSetChecker Test daemonset pod is still removing: kuberhealthy daemonset-daemonset-1603314019-1603314025-vrwwx on node ilt-lbx-g-kpx01"
time="2020-10-21T21:00:51Z" level=info msg="DaemonSetChecker using LabelSelector: app=daemonset-daemonset-1603314019-1603314025,source=kuberhealthy,khcheck=daemonset"
time="2020-10-21T21:00:51Z" level=info msg="DaemonSetChecker Daemonset check waiting for 0 pods to delete"
time="2020-10-21T21:00:51Z" level=info msg="DaemonSetChecker Test daemonset has finished removing pods"
time="2020-10-21T21:00:51Z" level=info msg="Error reporting success to Kuberhealthy servers: bad status code from kuberhealthy status reporting url: [400] 400 Bad Request "
time="2020-10-21T21:00:51Z" level=error msg="Error running check: DaemonSetChecker in namespace kuberhealthy: bad status code from kuberhealthy status reporting url: [400] 400 Bad Request "

For the kh_reporting_url, you'll need /externalCheckStatus at the end -- so http://kuberhealthy.kuberhealthy.svc.icp-global.local/externalCheckStatus
It seems like the daemonset is using the container image:
time="2020-10-21T21:00:30Z" level=info msg="Setting DS pause container override image to:fsnexus.evry.com:8085/google-containers/pause:3.1" ?

Yes, it's overridden in order to run in an air-gap environment.
However - it's the deployment check that's the issue, because it want to run as root:
k describe pod deployment-deployment-6d44bbc6d7-7f9nl |tail -6
  Type     Reason          Age                   From               Message
  ----     ------          ----                  ----               -------
  Normal   Scheduled       14m                   default-scheduler  Successfully assigned kuberhealthy/deployment-deployment-6d44bbc6d7-7f9nl to alt-eos-g-kwo02
  Normal   SandboxChanged  14m                   kubelet            Pod sandbox changed, it will be killed and re-created.
  Warning  Failed          12m (x12 over 14m)    kubelet            Error: container has runAsNonRoot and image will run as root
  Normal   Pulled          4m16s (x51 over 14m)  kubelet            Container image "nginx:1.17.8" already present on machine

It's possible to override the test images that the deployment check uses during its run; you can edit the environment variables CHECK_IMAGE and CHECK_IMAGE_ROLL_TO for the check:
  podSpec:
    containers:
    - name: deployment
      image: kuberhealthy/deployment-check:v1.6.2
      env:
        - name: CHECK_IMAGE
          value: "nginx:1.17-perl"
        - name: CHECK_IMAGE_ROLL_TO
          value: "nginx:1.17.5-perl"

Closing this as it works with the assistance given - thanks a lot!
Maybe you want to consider using the nginx-unprivileged container by default?


Unicode character insertion via tab-completion

Just like in *.jl and *.md files,
is there a way to get tab completion of unicode characters for Julia code blocks in *.typ files?

Related https://github.com/nvarner/typst-lsp/issues/49 which makes sense for scope. I'll close this.


Add new Rails/CreateTableWithTimestamps cop

Hi there,
The other day I made a mistake in forgetting to add timestamps when creating a new table :(
So, I want to prevent such simple mistakes by using RuboCop.
This cop checks the migration for which timestamps are not included when creating a new table. In many cases, timestamps are useful information and should be added.
WDYT?

Before submitting the PR make sure the following are checked:

[x] Wrote good commit messages.
[ ] Commit message starts with [Fix #issue-number] (if the related issue exists).
[x] Used the same coding conventions as the rest of the project.
[x] Feature branch is up-to-date with master (if not - rebase it).
[x] Squashed related commits together.
[x] Added tests.
[x] Added an entry to the Changelog if the new code introduces user-observable changes. See changelog entry format.
[x] All tests(rake spec) are passing.
[x] The new code doesn't generate RuboCop offenses that are checked by rake internal_investigation.
[x] The PR relates to only one subject with a clear title
and description in grammatically correct, complete sentences.
[x] Updated cop documentation with rake generate_cops_documentation (required only when you've added a new cop or changed the configuration/documentation of an existing cop).

This seems like a good idea. Here are some questions to consider:

Should this cop be restricted to db/migrations to avoid false positives?
Should this cop allow manually declaring updated_at and created_at (because timestamps does not configure a default value, for instance)?
Should manually declaring only one of created_at or updated_at satisfy this cop?

I'm ok with answering "no" to all of those, just asking ...

@mikegee Thanks for your questions.

Should this cop be restricted to db/migrations to avoid false positives?

Yes. That is a good idea. I will fix config/default.yml for restricting to db/migrates/*.rb

Should this cop allow manually declaring updated_at and created_at (because timestamps does not configure a default value, for instance)?

Yes. If they are declared manually, this cop should not add offenses. I will fix it.

Should manually declaring only one of created_at or updated_at satisfy this cop?

Yes. If a user explicitly declared only one of them, I think we can judge that a user has not forgotten to add a timestamp. I will also fix this.


registry for use with stateless services

With things like quick scripts or FaaS the lifetime is small. The current registries maintain state over a period of time and flush for that time. This is not applicable for many short lived use-cases. For these it would likely need to just flush the deltas to something like the internal side car.
/cc @jkschneider

@brharrington  Anything new about that? Is there a version of Spectator Client + Atlas Aggregator that we can test?


How to disable youtube playlist links

Our chat members keep accidentally copy/pasting Youtube playlist links when they want an individual song which causes the bot to queue up all songs in the play list. Some times they will copy paste multiple urls form the play list causing bot to queue up the full play list multiple times

You can change allowplaylist in the permissions file, or tell your members to use individual song links instead of ones from a playlist or have them take off the &list=blahblahblah

You can change allowplaylist in the permissions file, or tell your members to use individual song links instead of ones from a playlist or have them take off the &list=blahblahblah


Hooks for Read Operations

Reading the docs and code, it looks like ent exposes the ability to register hooks in mutating operations, but not on reads.  The use case I'm trying to solve for is one in which sensitive data is encrypted before being persisted to a database and then decrypted on subsequent reads, assuming the caller provides the appropriate keys/metadata.  Given the lack of read hooks, the approaches to this problem today seem to be limited to (1) encrypting in a mutation hook and decrypting in the application or (2) moving all encryption / decryption to the application.  (1) is less than ideal because of divergent and arguably non-intuitive implementations and (2) opens up a greater possibility of accidentally circumventing the rules.
Is there another approach to this scenario I'm not seeing?  If not, would the ent authors consider either adding this or accepting a contribution that adds this?

Hey @asonawalla and thanks for raising up this issue! I'll answer about it briefly and add more details about it tomorrow (it's a holiday evening atm here).
The only place for hooking into queries is the privacy layer (you won't find in the website, because docs is in progress). However, @alexsn and I just discussed about it yesterday, and agreed that we want to add support for read-hooks/interceptors. We thought about naming it as Interceptors, but we're not sure about the end design. So, you're welcome to start the discussion here and propose  the API (implementation should be simple).  Once we add this, the privacy layer will be migrated to this generic layer as well.

Perfect, I'll get a bit familiar with the privacy layer and circle back with any thoughts on API.  Enjoy your evening!

This is needed feature for us also, we want to inject some params to both read and write apis based user context. This is useful for security and customisation.

Hey, the privacy doc is available now in entgo.io/docs/privacy.

I've been thinking through my use case and the ideal API a bit more.  For symmetric encryption, defining a ReadHooks() method in the schema which has access to field getters and setters will be able to convert persisted ciphertext into plaintext once the query has been run.  Unfortunately modifying fields in this way would break the ability to use that field in a query predicate, e.g. it wouldn't be straightforward to look up a user based on an API key that's hashed in the DB but passed plain in the application.
This is very likely out of scope for this issue, but maybe the ideal solution to this problem is to offer even more granular hook capabilities that are evaluated independently of the DB?  Something that might compile to roughly:
type Entity struct {
  myField string // value that gets persisted
}

func (e *Entity) MyField() string {
  // optional custom getter logic e.g. decryption
}

func (e *Entity) SetMyField(v string) {
  // optional custom setter logic e.g. encryption
}

@a8m Is there an equivalent of a global hook in the privacy layer (i.e global privacy rule)?
AFAICT privacy rules are per-table, which makes it hard to use privacy layer as a means of keeping track of general DB query accesses (e.g for metrics)
this is obviously a misuse of the privacy layer, but its a workaround until  read-hooks are ready :P

@a8m Is there an equivalent of a global hook in the privacy layer (i.e global privacy rule)?
AFAICT privacy rules are per-table, which makes it hard to use privacy layer as a means of keeping track of general DB query accesses (e.g for metrics)
this is obviously a misuse of the privacy layer, but its a workaround until read-hooks are ready :P

a temporary workaround - wrapping *sql.DB in a custom dialect.Driver interface implementation that intercepts the Query function

Hey @yuvalt7, you can define a global privacy rule using a mixed-in schema. See this example in the doc.
I'm still working on designing the API for interceptors (read-hooks), but suggestions are welcome.

Also interested in this
Could possibly implement something simliar too ef core global filters
e.g. by default only retrieve active records
// will only retrieve active users
u, err := client.User.
        Query().
        Only(ctx)

// Remove default filters
u, err := client.User.
        Query().
        ClearGlobalFilters()
        Only(ctx)

@a8m An issue with the privacy layer workaround is not being able to defer a function call to the end of the query evaluation.
Is there another way to handle the query tracing use case?
It seems an API similar to hooks but for queries should work for this specific case.
client.Intercept(func(next ent.Query) ent.Query {
    return ent.QueryFunc(func(ctx context.Context, q ent.Query) (ent.Value, error) {
        start := time.Now()
        defer func() {
            log.Printf("Time=%s\tConcreteType=%T\n", time.Since(start), q)
        }()
        return next.Query(ctx, q)
    })
})

I've been thinking through my use case and the ideal API a bit more. For symmetric encryption, defining a ReadHooks() method in the schema which has access to field getters and setters will be able to convert persisted ciphertext into plaintext once the query has been run. Unfortunately modifying fields in this way would break the ability to use that field in a query predicate, e.g. it wouldn't be straightforward to look up a user based on an API key that's hashed in the DB but passed plain in the application.
This is very likely out of scope for this issue, but maybe the ideal solution to this problem is to offer even more granular hook capabilities that are evaluated independently of the DB? Something that might compile to roughly:
type Entity struct {
  myField string // value that gets persisted
}

func (e *Entity) MyField() string {
  // optional custom getter logic e.g. decryption
}

func (e *Entity) SetMyField(v string) {
  // optional custom setter logic e.g. encryption
}

I agree that for your specific use case, getter/setter approach seems to be more explicit and simple than read hooks

@gqgs did you figure it out how to add read hooks

We need to convert ent error to framework error, like this::
client.Use(func(next ent.Mutator) ent.Mutator {
        return ent.MutateFunc(func(ctx context.Context, m ent.Mutation) (ent.Value, error) {
            v, err := next.Mutate(ctx, m)
            return v, convertError(err)
        })
    })

// https://github.com/go-kratos/kratos/blob/main/errors/types.go
func convertError(err error) error {
	if err == nil {
		return nil
	}
	if ent.IsNotFound(err) {
		return errors.NotFound("DATA", err.Error())
	}
	return errors.InternalServer("DATA", err.Error())
}
``

any update about this feature?

+1

@gqgs hooks for tracing can look https://github.com/qustavo/sqlhooks

Hey! A quick update on this issue: the feature was implemented in https://github.com/ent/ent/pull/3157 and will be merged in the upcoming days. You're welcome to share your feedback or thoughts on the PR.

Closed with https://entgo.io/docs/interceptors 😃


No error when the return value of the function is an object

TypeScript Version:  4.1.2
Search Terms: function, return
Code
const example: () => { name: string } = () => {
  return {
    name: 'jhon',
    age: '20',　　　　// No error 👎
  };
};

Expected behavior:
The 'age' is not included in the definition and therefore should get an error.
Actual behavior:
No errors.
You will get an error if you do the following.
const example = (): { name: string } => {
  return {
    name: 'jhon',
    age: '20',　　　　// error 👍
  };
};

This is working as intended. Because you did not provide any type annotations for your arrow function the return type will be inferred. Then when assigning this function to your variable it will be checked for compatibility, which matches here.

@MartinJohns
Thank you for your answer.
The following code would result in an error on the editor and should show an error as well.
What do you think?

In your new example the types are not compatible. A string is not compatible with a boolean.
In your first example the types are compatible. { name: string; age: string } is compatible with { name: string }.

@MartinJohns
Understood.
Thank you for telling me.


A way to config the  threadpool

Why you need it?
When I try to translate Chinese into English,I found FrameworkErrorCode.ThreadPoolFull,its message is not perfectly right.The threadpool isn't belong to netty,and I cannot find a way  to config the threadpool unless you change the code.So I need a way to config it.
How it could be?
I can change the  config of  threadpool.
Other related information
Add any other context or screenshots about the feature request here.

ThreadPoolFull： netty channelRead -->user threadpool

Have you consider using disruptor as one of the implement of threadpool?


Set scope for all variables

This applies to number variables (only?)

Acceptance criteria:

Each number type variable in Figma EN library has the appropriate number scoping
Each number type variable in Figma FR library has the appropriate number scoping

@adorayi can we close this issue since this work is already scoped as part of #872


Request: Respect /team allies with effects

Minecraft has a built-in teams feature with an optional friendly fire toggle.
I'd like to request that when this is turned off(i.e. you cannot harm your teammates), negative effects from gear and enchantments do not affect your allies, but still affect players on other teams, as an alternative to having to turn off items affecting other players altogether.

Yeah I’ll see what I can do

Yeah I’ll see what I can do

Is this still an issue in the later versions that have been released?

I haven't yet had the opportunity to test an update of the mod in a multiplayer setting and am unsure if I will be able to anytime soon or not, but I'll see if I can figure out a way to test it with a friend in the near future.

Just tested with a friend. We were both on the same team, with friendly fire turned off(so we wouldn't damage each other), and using any artifact which does negative effects to nearby enemies still affect my teammate.
I apologize for not remembering the names of the items, but: the teammate was not launched by the book that launches nearby enemies into the air. And the beacon laser artifact doesn't damage a teammate, so that seems to be working properly. It's the application of negative potion effects that appears to be the problem.

I guess something messed up my original reply, so to summarize:
I tested with a friend, using several artifacts in their vicinity and at them when we were both on a team with friendly fire disabled.
Artifacts which cause damage did not damage them(as expected). Artifacts which purely did something to nearby enemies like launching them in the air didn't affect them(as expected). But anything that applies potion effects, positive or negative, still applies to teammates.
This is especially troublesome in the case of armor enchants that emit auras like slowing enemies and such.
So it seems like the main issue at this point is there being no differentiation between positive and negative potion effects where team-based allies are involved.

@Jackiecrazy you wanna take a look at this?

I rewrote the targetting a bit in the upcoming beta version. @Febilian , if you are still around, keep an eye on the next beta release. If it's still an issue in that version, please reply here.
Else I'll close thise a short while after releasing the version.

Closing because team targetting should now be included.


Allow React 18 as peer dependency

What kind of change does this PR introduce?
Updates package.json to allow react 18 as peer dependency, which is now stable.

instructions for setting changeset is here
https://github.com/supabase-community/auth-ui/blob/main/development.md#change-logs

Thanks for getting to this so quickly <3


add echarts-for-react & timeago-react

echarts-for-react baidu Echarts(v3.0) components for React wrapper. demo
timeago-react is a simple and efficient react component used to format date with *** time ago statement. eg: '3 hours ago'. demo

There was a problem with authentication for a subset of GitHub users. It's fixed now.
PRs are not convenient to manage, please add the entry to devarchy instead.

Added to devarchy.com.


Swift and Obj-C Discrepancy?

I'm working on an iOS app in Swift 3 and I'd like to get the MTMathUILabel and MTEditableMathLabel (from MathEditor) to display Matrices. I tried following the EXAMPLES.md file and even your example ViewController.m. When I set label.latex to be a "\begin{pmatrix} a & b\\ c & d \end{pmatrix}", I always just get "invalid command begin" on my label.
Since it works well in your example app, I'm wondering if this is caused by the fact I'm programming in swift. If not, looking for any advice to make this work. Thank you!

Just realized that this was caused by me having an old version of iosMath. I needed version 0.9.0 while MathEditor needs version 0.7.3

Yes, I need to update the MathEditor to use the latest version.

Is this something you're working on now?
If not, is there a way I can include both versions (0.9.0 and 0.7.3) in my xcode project?

I updated the MathEditor project to use the latest version.


AssertionError when trying execute ModelCompoundSelectQuery

  File "/usr/local/lib/python3.7/site-packages/peewee_async.py", line 258, in execute
    return (await execute(query))
  File "/usr/local/lib/python3.7/site-packages/peewee_async.py", line 395, in execute
    return (await coroutine(query))
  File "/usr/local/lib/python3.7/site-packages/peewee_async.py", line 640, in raw_query
    "with wrong query class %s" % str(query))
AssertionError: Error, trying to run delete coroutinewith wrong query class <peewee.ModelCompoundSelectQuery object at

Need a source code sample to reproduce.

Cannot comment on OP due to lack of context, but related to this, there is a bug in the error message
async def raw_query(query):
    assert isinstance(query, peewee.RawQuery),\
        ("Error, trying to run delete coroutine"
         "with wrong query class %s" % str(query))

"run delete coroutine" should be "run raw_query coroutine"


fix bug when upload file

The order of parameter of this function changed; so we have to switch the order of folderId with formData

Chen, I am fixing a few things on my branch. I will review this before the end of today.

I am able to upload a new file to a dataset on main. How do I reproduce the bug?

On main, you do a fresh npm run codegen:v2:dev then try upload the file again. You should see it fails @lmarini

A

On main, if you do a fresh npm run codegen:v2:dev then try upload the file again. You should see it fails @lmarini

Thanks, that makes sense


Request Creation: Not able to create the request in collection

When i try to create the request inside the collection getting the below error saying the request is already available
but actually, this is the first time I tried to add the request

Looks like we have an issue in Windows. Can you confirm your OS and which version you are using ?

Hi @helloanoop
Yes it windows machine

@sseenivasan89
I was able to reproduce your issue on windows. Will release a fix for this tonight. Please standby.

@sseenivasan89 Thank you so much 🙏 for submitting this issue.
There was some filename related issues for windows which has been fixed.
I have release v0.9.3
Can you please reinstall and check if this fixes your issue ?

@helloanoop - its working fine now

Awesome, Thanks @sseenivasan89 !


0.16. causes unresolved imports

I'm updating the dependencies of the librespot and some of them depend on cfg-expr 0.16. (e.g. glib 0.20.2). Building now fails with
Compiling cfg-expr v0.16.0
error[E0432]: unresolved imports `OperatingSystem::Hurd`, `OperatingSystem::Visionos`
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cfg-expr-0.16.0/src/expr.rs:265:63
    |
265 |                     Freebsd, Fuchsia, Haiku, Hermit, Horizon, Hurd, Illumos, Ios, L4re, Linux,
    |                                                               ^^^^ no `Hurd` in `targets::OperatingSystem`
266 |                     MacOSX, Nebulet, Netbsd, None_, Openbsd, Redox, Solaris, Tvos, Uefi, Unknown,
267 |                     Visionos, VxWorks, Wasi, WasiP1, WasiP2, Watchos, Windows,
    |                     ^^^^^^^^ no `Visionos` in `targets::OperatingSystem`

error[E0408]: variable `Hurd` is not bound in all patterns
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cfg-expr-0.16.0/src/expr.rs:271:21
    |
271 |                     Aix
    |                     ^^^ pattern doesn't bind `Hurd`
272 |                     | Darwin
    |                       ^^^^^^ pattern doesn't bind `Hurd`
273 |                     | Dragonfly
    |                       ^^^^^^^^^ pattern doesn't bind `Hurd`
274 |                     | Espidf
    |                       ^^^^^^ pattern doesn't bind `Hurd`
275 |                     | Freebsd
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
276 |                     | Fuchsia
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
277 |                     | Haiku
    |                       ^^^^^ pattern doesn't bind `Hurd`
278 |                     | Hurd
    |                       ---- variable not in all patterns
279 |                     | Illumos
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
280 |                     | Ios
    |                       ^^^ pattern doesn't bind `Hurd`
281 |                     | L4re
    |                       ^^^^ pattern doesn't bind `Hurd`
282 |                     | MacOSX { .. }
    |                       ^^^^^^^^^^^^^ pattern doesn't bind `Hurd`
283 |                     | Horizon
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
284 |                     | Netbsd
    |                       ^^^^^^ pattern doesn't bind `Hurd`
285 |                     | Openbsd
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
286 |                     | Redox
    |                       ^^^^^ pattern doesn't bind `Hurd`
287 |                     | Solaris
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
288 |                     | Tvos
    |                       ^^^^ pattern doesn't bind `Hurd`
289 |                     | Visionos
    |                       ^^^^^^^^ pattern doesn't bind `Hurd`
290 |                     | VxWorks
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
291 |                     | Watchos => fam == &crate::targets::Family::unix,
    |                       ^^^^^^^ pattern doesn't bind `Hurd`
    |
help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `path::to::ModOrType::Hurd`
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cfg-expr-0.16.0/src/expr.rs:278:23
    |
278 |                     | Hurd
    |                       ^^^^

error[E0408]: variable `Visionos` is not bound in all patterns
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cfg-expr-0.16.0/src/expr.rs:271:21
    |
271 |                     Aix
    |                     ^^^ pattern doesn't bind `Visionos`
272 |                     | Darwin
    |                       ^^^^^^ pattern doesn't bind `Visionos`
273 |                     | Dragonfly
    |                       ^^^^^^^^^ pattern doesn't bind `Visionos`
274 |                     | Espidf
    |                       ^^^^^^ pattern doesn't bind `Visionos`
275 |                     | Freebsd
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
276 |                     | Fuchsia
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
277 |                     | Haiku
    |                       ^^^^^ pattern doesn't bind `Visionos`
278 |                     | Hurd
    |                       ^^^^ pattern doesn't bind `Visionos`
279 |                     | Illumos
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
280 |                     | Ios
    |                       ^^^ pattern doesn't bind `Visionos`
281 |                     | L4re
    |                       ^^^^ pattern doesn't bind `Visionos`
282 |                     | MacOSX { .. }
    |                       ^^^^^^^^^^^^^ pattern doesn't bind `Visionos`
283 |                     | Horizon
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
284 |                     | Netbsd
    |                       ^^^^^^ pattern doesn't bind `Visionos`
285 |                     | Openbsd
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
286 |                     | Redox
    |                       ^^^^^ pattern doesn't bind `Visionos`
287 |                     | Solaris
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
288 |                     | Tvos
    |                       ^^^^ pattern doesn't bind `Visionos`
289 |                     | Visionos
    |                       -------- variable not in all patterns
290 |                     | VxWorks
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
291 |                     | Watchos => fam == &crate::targets::Family::unix,
    |                       ^^^^^^^ pattern doesn't bind `Visionos`
    |
help: if you meant to match on a variant or a `const` item, consider making the path in the pattern qualified: `path::to::ModOrType::Visionos`
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cfg-expr-0.16.0/src/expr.rs:289:23
    |
289 |                     | Visionos
    |                       ^^^^^^^^

   Compiling cfg-expr v0.15.8
   Compiling sdl2-sys v0.36.0
error[E0599]: no variant or associated item named `None` found for enum `target_lexicon::Environment` in the current scope
   --> /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/cfg-expr-0.16.0/src/expr.rs:203:52
    |
203 | ...                   | Environment::None
    |                                      ^^^^ variant or associated item not found in `Environment`
    |
help: there is a method `ne` with a similar name

This should be resolved in 0.17, the problematic dependency is now pinned since it has had other sever incompatibilities.


Generate project file from tmux session

Implements #61

[x] windows and panes
[x] layout
[x] path
[ ] commands
[ ] history

See also
http://manpages.ubuntu.com/manpages/precise/en/man1/tmux.1.html#contenttoc9
http://blog.edsantiago.com/articles/tmux-session-preserve/
http://zerokspot.com/weblog/2012/05/20/tmux-split-window-and-pwd/
https://github.com/mislav/dotfiles/blob/master/bin/tmux-session

this is a very useful feature, any reason to not merge this?

I agree, this looks useful.  However, I'd suggest moving this to Tmuxinator::Cli#new_from_session.  Also, some tests need to be added (not sure if spec/lib/tmuxinator/cli_spec.rb was around when this code was originally written, but it is now.

@adamstrickland it is about 2 years late for code nits like that IMO. Low chance the contributor will make it back to fix those. Might as well merge it then refactor however is necessary.

@ianks Yes, but I can make these fixes.

@ianks I agree, the chance is low, whether those are "nits" or not.  Speaking for myself, I don't like the idea of adding technical debt (one of those "nits" of which you speak), when in the intervening 2 years only but one or two contributors have been so inspired as to even express interest in furthering this functionality.
Regardless, since @DeepAnchor recently expressed such interest, perhaps they would be so inspired.  Or yourself, even, rather than leaving it to the original contributor.  But thank you for your opinion.

Thanks @pczarn.  Sorry this wasn't incorporated way back when :-/

Sorry if that came off wrong @adamstrickland, I just don't like seeing when a contributor puts a lot of time and effort into adding functionality to a project, just to have it ignored. I think its rather unfair. I'm happy it is working out this time though :smile:

@ianks Fair enough.  I agree, having been on the other end of a similar situation, it is both frustrating and unfair, especially well after the fact.  Which is why I responded now (my first chance) that @DeepAnchor raised the question.  That being said, the contributing guide pretty clearly states that tests are required in PRs...
Regardless, like you said, I'm happy this looks to be working out this time.  I just got back to my computer after some time off, so I personally am backed up for a few days, but I'll take a look myself at adding a test or two when I get a chance.  Hopefully we can get this :ship:ed ASAP.

I updated the code and added a test. I see a small problem which is adding low-level logic in Cli. Ideally parts of this code would be moved to some other files, but I'm not sure how to proceed.

Could you reopen? This PR was broken by the large difference in commit history.

@pczarn Unfortunately, it doesn't look like I can reopen this one, since it says that there are no commits between your serialize-session branch and our 0.7.0-wip branch. It seems the large difference in commit history was simply because this pull request was opened against that 0.7.0-wip branch, which is very out-of-date.
Could you push up your changes to your serialize-session branch again open a new pull-request against our master branch?

Done, the new PR is #426


time zone handling in documentation

https://microsoft.github.io/yardl/reference/binary.html#dates-times-and-datetimes isn't clear on time zone handling. DateTimes is clear enough, (although a reference to what "since epoch" means would be good) but the doc on Dates and Times should say this is in UTC presumably. That might be undesirable/confusing though, so maybe it's better to support time zones spec.
Also, I'm assuming the types are actually singular, e.g. DateTime. I think a different font needs to be used for the actual type name (like you use for float etc).

That's good feedback. One of the challenges is that Numpy's datetime64 type does not store time zone offset information. So I think we either state that datetimes are "naive" and have no knowledge of time zones, or we say that they are assumed/required to be UTC. The other option is creating another data type that can be used in NumPy arrays that has time zone information. But that will bring other challenges and perhaps complicate adoption.

I don't care too much if numpy is limited. yardl shouldn't be 😄 .
If you say that DateTime is secs (or whatever) since the epoch, it is time zone dependent. The epoch is  a specific time in UTC.
I have no idea how "seconds since epoch" is computed (i.e. taking leap years/seconds etc into account or not). There's probably an RFC or other standard on that somewhere, which you could/should refer to.
An apparently frequently referenced/debated set of suggestions is https://apiux.com/2013/03/20/5-laws-api-dates-and-times/
By the way, I think that using "nanosecs since epoch" is probably asking for trouble, given possible uncertainty on leap secs and all that. This goes well beyond what I know about time conventions though.
We do need a "TimeZone" type I believe. We definitely want to be able to store this.


Add null/empty check

I was getting an IndexOutOfRangeException from a server announcement feed

Codecov Report

Merging #5 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master       #5   +/-   ##
=======================================
  Coverage   95.93%   95.93%
=======================================
  Files          41       41
  Lines        1131     1131
  Branches       76       76
=======================================
  Hits         1085     1085
  Misses         19       19
  Partials       27       27

Impacted Files
Coverage Δ

src/NetIRC/Messages/RplNamReplyMessage.cs
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e047fce...366af13. Read the comment docs.

Thanks!

Actually looking back at this, was there a particular reason that you're using character indices for this instead of just string.StartsWith()?


Improved comments

I'm looking forward to contributing more to this project! As I was familiarizing myself with the code, I added some more comments to the program's functions so that they'd be easier to navigate. To this end, there were also a few lines of commented-out code I removed, and some spaces I added so that different "sections" within a function were more clearly delineated.

Good to go. Thanks again for the PR


multi-LORA

Is it possible to use multiple LORAs for synchronized forecasting?
for example, I trained LORA for two separate tasks. When predicting, I want to load both LORA weights at the same time to perform the task of punctuation and case recovery at the same time

same question, did you find the answer?

same question, did you find the answer?

same question, did you find the answer?

would the batching and scheduling approaches in S-LoRA https://arxiv.org/abs/2311.03285 be useful in your case ?

Is it possible to use multiple LORAs for synchronized forecasting?
for example, I trained LORA for two separate tasks. When predicting, I want to load both LORA weights at the same time to perform the task of punctuation and case recovery at the same time

This is possible. One way is to first load the first adapter as usual with PeftModel.from_pretrained. Next you could merge_and_unload the model, so that you get a model with the first adapter baked in. Now repeat the loading process, passing the merged model to PeftModel.from_pretrained. Optionally, you can merge and unload again after this step.
Alternatively, after loading the first adapter, you could load the next adapter using model.add_adapter("adapter-2", config2), and then activate both of them using model.base_model.set_adapter(["default, "adapter-2"]). This is a bit of a hidden feature that we haven't documented yet, but it should work. Use this option if you don't want to merge the adapters.

would the batching and scheduling approaches in S-LoRA https://arxiv.org/abs/2311.03285 be useful in your case ?

From my understanding, S-LoRA is especially useful in situations where you want to serve hundreds of LoRA adapters.

We have implemented a synchronous training approach multi-lora-fine-tune and the ideas for synchronous prediction and synchronous training should be similar:

fuse input data into a large batch, sharing the base model during computation
break down the fused information into different matrices when passing through the LoRA module. This allows for calculations with different LoRA modules.

Due to significant differences in data volume between prediction and training when passing through the LoRA module, special CUDA operators may be needed for optimization. You can refer to how S-LoRA  implements this operator.


ENH accelerate _mixed_norm_solver_bcd by using blas (instead of np.dot) for the matrix multiplication in the BCD

What does this implement/fix?
I accelerated the strangely slow function _mixed_norm_solver_bcd using blas (instead of np.dot) for the matrix multiplication in the Block Coordinate Descent.
Additional information
The _mixed_norm_solver_bcd solver of MNE relies on Block Coordinate Descent (BCD, when calling  _mixed_norm_solver_bcd solver 95% of the time is spent in the BCD).
 I tried to speed it up.
I tried using numba for the BCD, however it did not speed up the function _mixed_norm_solver_bcd.
I looked at the most costly operations (with a line profiler), it turned out to be the np.dot operations:

https://github.com/mne-tools/mne-python/blob/767cd9246370d25b132b4d98206095e15779044f/mne/inverse_sparse/mxne_optim.py#L349
https://github.com/mne-tools/mne-python/blob/767cd9246370d25b132b4d98206095e15779044f/mne/inverse_sparse/mxne_optim.py#L353
https://github.com/mne-tools/mne-python/blob/767cd9246370d25b132b4d98206095e15779044f/mne/inverse_sparse/mxne_optim.py#L363
I changed the np.dot operations for scipy.linalg.get_blas_funcs operations.
This led to a 2 to 3 factor improvement in the speed.

Speed up: numbers
On the Sample dataset with oct6 resolution, free orientation and alpha=10 (ie. alpha set to 10% of alpha_max) it takes me more than 80sec with the np.dot version and 25sec with the scipy blas function.
The script used to benchmark the version can be found here: https://gist.github.com/QB3/9fe852003ffc5b6b2117670156a4c66c.

There is no speed in the tests, however there is a gain in speed on real data, for instance in the sample dataset: https://gist.github.com/QB3/9fe852003ffc5b6b2117670156a4c66c.

can you share numbers so we don't have to do the experiment? #lazy

I added it in the description, on the Sample dataset with oct6 resolution, free orientation and alpha=15 (ie. alpha set to 15% of alpha_max) it takes me more than 70sec with the np.dot version and 35sec with the scipy blas function.

@QB3 travis is not happy https://travis-ci.org/mne-tools/mne-python/jobs/524400756

@QB3 can you update what's new? thx

I am trying to make "make pep" work on my computer

Let me know when I should look

everything pass the tests and should be clean now

I pushed force to modified the name of a commit, sorry.

Thanks @QB3 !


Add listToMD5

@nvnieuwk you can ping me on slack when it's obvious I haven't seen the github notification

Oh yeah I completely forgot about this one :grin:


Docstring linting cleanup

Pull Request Checklist:

[ ] This PR addresses an already opened issue (for bug fixes / features)

This PR fixes issue #xyz

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Documentation has been added / updated (for bug fixes / features)
[ ] HISTORY.rst has been updated (with summary of main changes)
[ ] I have added my relevant user information to AUTHORS.md

What kind of change does this PR introduce?:

Updates pre-commit hooks, pins linting tools to their pre-commit equivalents
Adds a configuration for codespell
Fixes a few docstrings, specifies some class methods as static methods
Renames a few internal variables for clarity, rephrased a few sentences for grammar/spelling

Does this PR introduce a breaking change?:
No.
Other information:
https://github.com/codespell-project/codespell

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

-3 of 32 (90.63%)  changed or added relevant lines in 3 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.03%) to 72.391%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

clisops/ops/base_operation.py
15
18
83.33%

Files with Coverage Reduction
New Missed Lines
%

clisops/ops/average.py
1
81.25%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
1741

Relevant Lines:
2405

💛  - Coveralls

@Zeitsperre can we merge PR #319 before this one?


Use type name in error messages and inline doc

TypeScript Version:  2.4.0
Code
const foo = {
  name: 'Foo',
  age: 20,
}
type Foo = typeof foo;

function test(foo: Foo) { }

test('');

Expected behavior:
I'd like the error message to be:
Argument of type '""' is not assignable to parameter of type Foo

And the inline doc to be:
function test(foo: Foo): void

Actual behavior:
But the error message is
Argument of type '""' is not assignable to parameter of type '{ name: string; age: number; }'.

And the inline doc is
function test(foo: {
    name: string;
    age: number;
}): void

In this example, the current behavior is alright but in more complicated situations the error messages can become very verbose and intimidating. Using the types name would make them a lot cleaner IMO.

Type aliases are just aliases, and they are eagerly resolved to what they alias by the compiler. This saves the compiler time and space when dealing with types. we try to do a reverse lookup process when we are writing the type name, but there is a limit to that.

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.


Fix NPE when observing history in CLI

What changed?
Return error out from iterator instead of trying to look at the history events in the response (which is nil).

Why?
After context timeout expires workflow observe crashes with NPE.

How did you test it?
./cadence --ct 5 --do cadence-canary workflow observe --wid cadence.canary.cron
Progress:
  1, 2022-01-27T13:55:32Z, WorkflowExecutionStarted
  2, 2022-01-27T13:56:02Z, DecisionTaskScheduled

Result:
  Run Time: 5 seconds

Potential risks

Release notes

Documentation Changes

Pull Request Test Coverage Report for Build 4d2e0d7a-e581-4d9b-9a7d-70467b05dd0e

1 of 2 (50.0%)  changed or added relevant lines in 1 file are covered.
65 unchanged lines in 11 files lost coverage.
Overall coverage decreased (-0.004%) to 56.895%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

tools/cli/util.go
1
2
50.0%

Files with Coverage Reduction
New Missed Lines
%

service/history/queue/timer_queue_processor_base.go
1
77.92%

tools/cli/util.go
1
49.87%

common/task/fifoTaskScheduler.go
2
84.54%

common/task/weightedRoundRobinTaskScheduler.go
2
89.64%

service/history/queue/timer_queue_processor.go
2
58.37%

service/history/queue/transfer_queue_processor.go
2
56.86%

common/persistence/nosql/nosqlplugin/cassandra/workflow.go
3
55.49%

common/persistence/nosql/nosqlplugin/cassandra/workflowUtils.go
8
77.95%

common/persistence/nosql/nosqlplugin/cassandra/tasks.go
14
72.8%

common/persistence/nosql/nosqlplugin/cassandra/workflowParsingUtils.go
14
87.9%

Totals

Change from base Build cb62f12e-a4f1-4da2-b9e7-b591093779d0:
-0.004%

Covered Lines:
83036

Relevant Lines:
145946

💛  - Coveralls


More two-letter reserved keywords

You need to catch GO, IF, OR, ST, and TI.

Thanks for that - I've added them in.


Integrate web3 login

Implement Polkadot.js extension wallet signing for web3 login support.

assign this to me , if it's okay for you !

Thanks for contributing, let me know if you have any questions or require help with the source code!


Change title image

</Tech> -> <Tech/>
fix #17

As we checked, it was the designer's intention. :)

I agree with the designer's choice!

then, would anybody approve this PR, please?


Help build support for WebAssembly

WebAssembly is a new technology for running code at near-native speed in browsers. A group of folks on the .NET team worked together to see what WebAssembly might look like using CoreRT. You can try the demo here using Firefox or Chrome!
We think CoreRT might be a good WebAssembly runtime since it builds IL to "native code" ahead-of-time and has a very small runtime. We’ve recently merged initial changes that get a simplified Hello World running using the LLVM API and Emscripten to produce WebAssembly. Now we’d like your help making it bigger and better! Right now, our goals are:

Be able to run an application big and interesting enough to show whether CoreRT really is a good match for WebAssembly. Blazor would be a great eventual goal.
Learn what makes good .NET WebAssembly applications.

This project is an experiment and has no current plans for a production-ready version. Your involvement can help us prove out this project. The best way you can help right now is to contribute code, but we’d also appreciate issues, ideas and questions to help us learn more about the way you want to use WebAssembly. For more technical details, there’s a design document here.
CoreRT is joining our friends in the ASP.NET Blazor and Mono WebAssembly projects in a set of open experiments on making .NET support WebAssembly. It’s an exciting space and one well-suited to an application platform with the characteristics of .NET.
Contributing code
We’ve filed a bunch of issues that break the work down into small tasks and they’re all up for grabs! Even if you don’t have experience with CoreRT, LLVM or WebAssembly, many of them should be doable. Look for the arch-wasm label. Most of the issues right now track implementing individual IL opcodes, which will enables us to compile more of the framework, but we also have issues for building, runtime features and the framework. Instructions for building and running WebAssembly are here.
Current status
Currently, just enough IL operations to build a simplified Hello World have been implemented. We haven’t finished compiling the runtime for assembly WebAssembly since we can get by without it for now, but we’ll need it for garbage collection, exception handling, virtual calls and higher-level framework features like reflection.

Are there anything won't possible for current webassembly? Such as Reflection.Emit

@Thaina, it's a little early to say for sure what would work eventually. The current WebAssembly spec has lots of missing features. For some of those cases, such as garbage collection and threading, we can build workarounds at the cost of efficiency.
On Reflection.Emit specifically, WebAssembly doesn't currently allow for JITs (and CoreRT doesn't currently have one). It might be possible to build new modules on the fly and get JavaScript to load them, but that's not entirely clear. It might be possible to add an interpreter to CoreRT if we need Reflection.Emit without the ability to JIT.
Did you have any particular usage in mind when you asked about Reflection.Emit (or other features)?

@morganbr Nothing in particular. It just that almost all AoT compiler cannot support that feature and all things relate to that (such as Expression.Compile). So it came to my mind first

wait and hope

@morganbr WASM needs its own GC to be perform well? Many GC designs are different depending on how the lang works. Ugg, this is why NaCl/PNaCl was better.. you could have just used the .NET GC with some tweaks and everything would have been fine, fast and low resource... just like Mono was with NaCl.
How did tech rooted FireFox's asm.js concepts win out here... People need to go take a look at just how much insanely faster Unity3D's NaCl version was over asm.js or WASM... its about 10x better in everyway it memory serves. I could run Unity NaCl builds on old PCs with very little ram and cpu usage. Such a regression. Sorry not the place for this.

@zezba9000, we're planning to use the .NET GC. As you say, we just have to make some adjustments to how it finds live objects.

What I meant in my earlier comment about "missing features" and GC is that WebAssembly doesn't let programs inspect the stack, which is important for finding live objects. We have to work around that by managing our own "shadow stack" elsewhere that the GC can inspect. If WebAssembly adds general GC support, it might let us do more efficient inspection and not need a shadow stack.

@morganbr Ok tnx for clearing that up. So not being able to support stack scanning is part of the missing GC features in wasm. I see. I know PNaCl supported this but did asm.js support this btw? My guess is no.
I see what you mean by slowing stuff down. I wonder if its even worth spending time making a GC shadow stack hack as the performance probably has an insane hit.

You can try the demo here using Firefox or Chrome!

Also works in Edge! 😄
about:config -> Enable experimental JavaScript features. In the upcoming v16, wasm will be enabled by default https://twitter.com/MSEdgeDev/status/894607665334177792

I've confirmed the demo works on Safari 11 as well and updated the post 😄

Update December 27:
As of #5141, we have a WebAssembly version of the runtime building and linked into generated WebAssembly code. Note that the instructions for building WebAssembly have changed to incorporate the new build flavor. We also have implementations of most of the important IL opcodes, but we're still missing some key ones including arrays and casting.
A good goal for the near future would be to get Console.WriteLine working (we currently print with a P/Invoke to printf). That will unblock running other tests. To do that, we need:

[ ] Delegates for Console.Out (#5143)
[ ] Static constructor triggering to get the output stream initialized (#4532)
[ ] Arrays to support static constructor triggering code (#4540

Update February 3:
We've made some big steps forward in compilation since the last update including:

Support for arrays (thanks to @hippiehunter)
Casting (@Blealtan)
Enabling building WASM on Mac and Linux (@christianscheuer)
Filling in more opcodes (@yaram and @morganbr)
Bug fixes (everybody!)

At this point, we have at least partial implementations for the common IL opcodes. We can start focusing more on hooking up runtime features such as interface dispatch (https://github.com/dotnet/corert/issues/4515) and exceptions (#4655). It's also about time to start porting framework features that depend on external libraries (globalization, networking, cryptography, etc) (https://github.com/dotnet/corefx/issues/26107).

Sorry for the slow response, @otabekgb. I was hoping to have https://github.com/dotnet/corefx/pull/28936 done for a bigger post, but, here's what we have for the moment:
The data structures for runtime features are now hooked up properly. @hippiehunter built interface dispatch on top of that.  I've also done a bit of optimizing, although that won't be a major focus until we have more scenarios working.
The next major step is to get CoreFX libraries building (starting with https://github.com/dotnet/corefx/pull/28936) and start porting framework features. We could also use better test coverage.
Since this is an experiment, we don't have specific ETA. Of course, community contributions both help us get closer to running Blazor and they're a great motivator.

I just saw video made by QT (C++). They showed fully functional solution for Web Assembly which looks insane. I think it is based on QT Lite but not sure...
Too bad there is nobody at Microsoft .NET team to realize importance of Web Assembly :( ... but Microsoft as usual... same old story...
Thank you guys for all the current work you did. Even without GC and exceptions support this is great job you did  !!!

@dax-l not sure if you've seen it but there is https://github.com/aspnet/Blazor 😃

So what is the current plan for web assembly and blazor? Use mono or corert? Are they both being developed for wasm at the same time ?

@stavroskasidis They're using Mono. CoreRT still has a ways to go I believe. I don't think CoreRT has a strong WASM focus yet while Mono does. Mono was ported to run on PNACL and has a longer cross platform focus in general.

@stavroskasidis see https://github.com/aspnet/Blazor/issues/286#issuecomment-373961638 for some info on this

@stavroskasidis, that comment is accurate -- current Blazor development is using Mono. That said, we're still pushing WebAssembly on CoreRT forward (albeit slower than Mono) to see if it will provide a better retail experience through small size and fast startup.

Update September 9:
There's been some great progress lately including:

Enabling simple debugging in Chrome and VS Code with stepping and local variables (see screenshot below)
We can build CoreFX libraries targeting WebAssembly. I've tested Console.WriteLine from CoreFX locally (using them involves manually copying libraries until we enable an official build)
Initial performance data showing potential for large speedups over the Mono interpreter (we haven't tested against Mono AoT, which should be similar to CoreRT).
Important bug fixes, thanks to @Blealtan and @yowl for their help finding and fixing them
Progress on safety checks, thanks to @hippiehunter
Optimizations for size and speed
@yowl is also making steady progress toward enabling reflection

If you'd like to help out, it would make a big difference! You can take a look at the open issues or play around with the test and see if you can find bugs (you probably can!).

@morganbr @yowl @hippiehunter Good work guys! How far we are from point where we will be able to use it in Blazor?

I would like to look at the #6476 as I've being doing bindings on Blazor for a while.
Is there any gitter/slack room that we can talk about that?

@galvesribeiro, sounds great! You can find some of us on the CoreRT gitter at https://gitter.im/dotnet/corert. If you have questions for Mono folks, I think they're in https://gitter.im/mono/mono.

IMO, this project should have more resources.
Sure, mono is already working on wasm as an interpreter and they are currently working on AOT compilation, but long-term this should be the runtime to use for blazor.
Just the fact that is a smaller runtime (and arguably faster too), is a win in my mind.

@stavroskasidis Looking forward to Xamarian.Forms or better a UWP sub-set or other XAML based and type safe mark-up that generates code in a partial class (for compile-time errors NOT runtime ones like all HTML build systems are full of) in the browser tbh. Blazer is two steps back and one step forward vs what Silverlight was when it comes to productivity for web apps. CoreRT opens up all these possibilities and thus does seem like it should be a higher profile project.

As far as https://github.com/nventive/Uno is concerned, it should be possible to run on top of CoreRT once nuget has proper TFM support to discriminate with mono-wasm.

Blazor using CoreRT in 2019 !!
Let's make it happen 😄