Talos Support

Talos is becoming more popular but currently the csi-driver doesn't work with it. If we need to do manual configuration of things like the iscsi and multipath we can do that by pushing values/files in the machine config. But the biggest hitch to me appears to be the requirement to create and mount /etc/hpe-storage on the host. That works on CoreOS but does not on Talos because basically the whole system is RO.
From what I can see that mount is needed to store a unique id for the node, couldn't you use the already existing unique ide and store specific data in ConfigMaps.

Hey, thanks for the interest! We've been kicking this around for a bit and I filed an internal JIRA to move the identifier to the Kubernetes control-plane instead. I've had some heated conversations with Andrew from the Talos project and I'm not 100% sure moving the identifier to Kubernetes will solve all our problems.
 That is the fastest route.

I don't think moving the ID to the control plane would solve all the problems, but it's a start. Maybe at least making it possible to set the /etc/hpe-storage mount path so we can specify Talos' ephemeral environment? It's possible with Kustomize but that's an extra step. I do plan on talking with our account rep but wanted to get it on the board here.

Internal JIRA is CON-1838.

Hi, are there any news about support for Talos?

It did not make it into the 2.5.0 release. I was going to do some research on it but it got delayed.

I'm glad to hear that it is actively being pursued at least. I will likely be deploying a new cluster in the relatively near future and it would be nice to be able to start with Talos

I try not to be the one pinging for updates all the time. But I need to start deploying a bare metal Kubernetes cluster soon and I'm in a bit of a planning pickle. I'd really like to just start with Talos but can't because of the need to use Nimble for PVs. I can start with a kubeadm cluster and later migrate to Talos, but that would mean putting a bunch of effort into setting up deployment workflows that may just be abandoned shortly after. So I'm not sure how much effort I should invest in automation vs just rolling by hand for now, or using an alternative storage.
I can understand 2.5 is out of the picture, it looks like there're already betas for that. So is this planned to be included in 2.6, which based on previous release cadence we may see before EOY or perhaps a 2.5.x release? Or is this planned for a longer timeframe like next year. Just trying to get an idea to help with planning.

It's hard for me to gauge when we can get to a stage to support Talos and immutable nodes in general. It's very high on my list but I rarely get my way when large deals are on the table demanding feature X, Y and Z.
Also, full disclosure, we have not even scoped the next minor or patch release as we're neck deep stabilizing 2.5.0. I'll make a note and try to get it in for consideration in the next couple of releases.
If you want to email me directly at michael.mattsson at hpe.com with your company name and business relationship with HPE it will make it easier for me to talk to product management.

I don't have a Talos environment readily available and skimming through the docs I realize I need firewall rules or deploy a new deployment environment for Talos itself.
As a quick hack, can you tell me how far you get with this?
helm repo add datamattsson https://datamattsson.github.io/co-deployments/
helm repo update
helm install my-hpe-csi-driver -nhpe-storage datamattsson/hpe-csi-driver --version 2.5.0-talos --set disableNodeConfiguration=true

It looks like it is still mounting /etc/hpe-storage and causing failures due to the RO filesystem
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-06-21T18:34:59Z"
  generateName: hpe-csi-node-
  labels:
    app: hpe-csi-node
    controller-revision-hash: 6cc9c89c6b
    pod-template-generation: "1"
    role: hpe-csi
  name: hpe-csi-node-tsvkz
  namespace: hpe-storage
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: DaemonSet
    name: hpe-csi-node
    uid: 280184d8-2211-44a8-9829-4d182242cb65
  resourceVersion: "7099"
  uid: 29d72260-ce51-4e52-8050-f975d54eacbc
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchFields:
          - key: metadata.name
            operator: In
            values:
            - talos-nvj-4af
  containers:
  - args:
    - --csi-address=$(ADDRESS)
    - --kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)
    - --v=5
    env:
    - name: ADDRESS
      value: /csi/csi.sock
    - name: DRIVER_REG_SOCK_PATH
      value: /var/lib/kubelet/plugins/csi.hpe.com/csi.sock
    - name: KUBE_NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName
    image: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.1
    imagePullPolicy: IfNotPresent
    name: csi-node-driver-registrar
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /csi
      name: plugin-dir
    - mountPath: /registration
      name: registration-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-lw749
      readOnly: true
  - args:
    - --endpoint=$(CSI_ENDPOINT)
    - --node-service
    - --flavor=kubernetes
    - --node-monitor
    - --node-monitor-interval=30
    env:
    - name: CSI_ENDPOINT
      value: unix:///csi/csi.sock
    - name: LOG_LEVEL
      value: info
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName
    - name: DISABLE_NODE_CONFIGURATION
      value: "true"
    - name: KUBELET_ROOT_DIR
      value: /var/lib/kubelet
    image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imagePullPolicy: IfNotPresent
    name: hpe-csi-driver
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        add:
        - SYS_ADMIN
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /csi
      name: plugin-dir
    - mountPath: /var/lib/kubelet
      mountPropagation: Bidirectional
      name: pods-mount-dir
    - mountPath: /host
      mountPropagation: Bidirectional
      name: root-dir
    - mountPath: /dev
      name: device-dir
    - mountPath: /var/log
      name: log-dir
    - mountPath: /etc/hpe-storage
      name: etc-hpe-storage-dir
    - mountPath: /etc/kubernetes
      name: etc-kubernetes
    - mountPath: /sys
      name: sys
    - mountPath: /run/systemd
      name: runsystemd
    - mountPath: /etc/systemd/system
      name: etcsystemd
    - mountPath: /opt/hpe-storage/nimbletune/config.json
      name: linux-config-file
      subPath: config.json
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-lw749
      readOnly: true
  dnsConfig:
    options:
    - name: ndots
      value: "1"
  dnsPolicy: ClusterFirstWithHostNet
  enableServiceLinks: true
  hostNetwork: true
  initContainers:
  - args:
    - --node-init
    - --endpoint=$(CSI_ENDPOINT)
    - --flavor=kubernetes
    env:
    - name: CSI_ENDPOINT
      value: unix:///csi/csi.sock
    image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imagePullPolicy: IfNotPresent
    name: hpe-csi-node-init
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        add:
        - SYS_ADMIN
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /host
      mountPropagation: Bidirectional
      name: root-dir
    - mountPath: /dev
      name: device-dir
    - mountPath: /sys
      name: sys
    - mountPath: /etc/hpe-storage
      name: etc-hpe-storage-dir
    - mountPath: /run/systemd
      name: runsystemd
    - mountPath: /etc/systemd/system
      name: etcsystemd
    - mountPath: /csi
      name: plugin-dir
    - mountPath: /var/lib/kubelet
      name: pods-mount-dir
    - mountPath: /var/log
      name: log-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-lw749
      readOnly: true
  nodeName: talos-nvj-4af
  preemptionPolicy: PreemptLowerPriority
  priority:<PHONE_NUMBER>
  priorityClassName: system-node-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: hpe-csi-node-sa
  serviceAccountName: hpe-csi-node-sa
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoSchedule
    key: csi.hpe.com/hpe-nfs
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/disk-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/memory-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/pid-pressure
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/unschedulable
    operator: Exists
  - effect: NoSchedule
    key: node.kubernetes.io/network-unavailable
    operator: Exists
  volumes:
  - hostPath:
      path: /var/lib/kubelet/plugins_registry
      type: Directory
    name: registration-dir
  - hostPath:
      path: /var/lib/kubelet/plugins/csi.hpe.com
      type: DirectoryOrCreate
    name: plugin-dir
  - hostPath:
      path: /var/lib/kubelet
      type: ""
    name: pods-mount-dir
  - hostPath:
      path: /
      type: ""
    name: root-dir
  - hostPath:
      path: /dev
      type: ""
    name: device-dir
  - hostPath:
      path: /var/log
      type: ""
    name: log-dir
  - hostPath:
      path: /etc/hpe-storage
      type: ""
    name: etc-hpe-storage-dir
  - hostPath:
      path: /etc/kubernetes
      type: ""
    name: etc-kubernetes
  - hostPath:
      path: /run/systemd
      type: ""
    name: runsystemd
  - hostPath:
      path: /etc/systemd/system
      type: ""
    name: etcsystemd
  - hostPath:
      path: /sys
      type: ""
    name: sys
  - configMap:
      defaultMode: 420
      name: hpe-linux-config
    name: linux-config-file
  - name: kube-api-access-lw749
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:35:00Z"
    status: "True"
    type: PodReadyToStartContainers
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:34:59Z"
    message: 'containers with incomplete status: [hpe-csi-node-init]'
    reason: ContainersNotInitialized
    status: "False"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:34:59Z"
    message: 'containers with unready status: [csi-node-driver-registrar hpe-csi-driver]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:34:59Z"
    message: 'containers with unready status: [csi-node-driver-registrar hpe-csi-driver]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:34:59Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - image: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.1
    imageID: ""
    lastState: {}
    name: csi-node-driver-registrar
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        reason: PodInitializing
  - image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imageID: ""
    lastState: {}
    name: hpe-csi-driver
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        reason: PodInitializing
  hostIP: <IP_ADDRESS>
  hostIPs:
  - ip: <IP_ADDRESS>
  initContainerStatuses:
  - image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imageID: ""
    lastState: {}
    name: hpe-csi-node-init
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        message: 'failed to generate container "d1bfa53cdae544c0b62c5d36c001fc2f7270357ac5bcf01691257ae999dbc058"
          spec: failed to generate spec: failed to mkdir "/etc/hpe-storage": mkdir
          /etc/hpe-storage: read-only file system'
        reason: CreateContainerError
  phase: Pending
  podIP: <IP_ADDRESS>
  podIPs:
  - ip: <IP_ADDRESS>
  qosClass: Burstable
  startTime: "2024-06-21T18:34:59Z"

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2024-06-21T18:42:38Z"
  generateName: hpe-csi-controller-574bc6ccf9-
  labels:
    app: hpe-csi-controller
    pod-template-hash: 574bc6ccf9
    role: hpe-csi
  name: hpe-csi-controller-574bc6ccf9-bzpb5
  namespace: hpe-storage
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: hpe-csi-controller-574bc6ccf9
    uid: 5b8c38be-808a-4293-b80a-b7780843bc8b
  resourceVersion: "7487"
  uid: 727b54dc-e0b6-4281-b6a4-4cbd297a592f
spec:
  containers:
  - args:
    - --csi-address=$(ADDRESS)
    - --v=5
    - --extra-create-metadata
    - --timeout=30s
    - --worker-threads=16
    - --feature-gates=Topology=true
    - --immediate-topology=false
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi.sock
    image: registry.k8s.io/sig-storage/csi-provisioner:v4.0.1
    imagePullPolicy: IfNotPresent
    name: csi-provisioner
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --v=5
    - --csi-address=$(ADDRESS)
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi.sock
    image: registry.k8s.io/sig-storage/csi-attacher:v4.5.1
    imagePullPolicy: IfNotPresent
    name: csi-attacher
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --v=5
    - --csi-address=$(ADDRESS)
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi.sock
    image: registry.k8s.io/sig-storage/csi-snapshotter:v7.0.2
    imagePullPolicy: IfNotPresent
    name: csi-snapshotter
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy/
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --csi-address=$(ADDRESS)
    - --v=5
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi.sock
    image: registry.k8s.io/sig-storage/csi-resizer:v1.10.1
    imagePullPolicy: IfNotPresent
    name: csi-resizer
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --endpoint=$(CSI_ENDPOINT)
    - --flavor=kubernetes
    - --pod-monitor
    - --pod-monitor-interval=30
    env:
    - name: CSI_ENDPOINT
      value: unix:///var/lib/csi/sockets/pluginproxy/csi.sock
    - name: LOG_LEVEL
      value: info
    image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imagePullPolicy: IfNotPresent
    name: hpe-csi-driver
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy
      name: socket-dir
    - mountPath: /var/log
      name: log-dir
    - mountPath: /etc/kubernetes
      name: k8s
    - mountPath: /etc/hpe-storage
      name: hpeconfig
    - mountPath: /host
      name: root-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --v=5
    - --csi-address=$(ADDRESS)
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi-extensions.sock
    image: quay.io/hpestorage/volume-mutator:v1.3.6-beta
    imagePullPolicy: IfNotPresent
    name: csi-volume-mutator
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy/
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --v=5
    - --csi-address=$(ADDRESS)
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi-extensions.sock
    image: quay.io/hpestorage/volume-group-snapshotter:v1.0.6-beta
    imagePullPolicy: IfNotPresent
    name: csi-volume-group-snapshotter
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy/
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --v=5
    - --csi-address=$(ADDRESS)
    env:
    - name: ADDRESS
      value: /var/lib/csi/sockets/pluginproxy/csi-extensions.sock
    image: quay.io/hpestorage/volume-group-provisioner:v1.0.6-beta
    imagePullPolicy: IfNotPresent
    name: csi-volume-group-provisioner
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy/
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  - args:
    - --v=5
    - --endpoint=$(CSI_ENDPOINT)
    env:
    - name: CSI_ENDPOINT
      value: unix:///var/lib/csi/sockets/pluginproxy/csi-extensions.sock
    - name: LOG_LEVEL
      value: info
    image: quay.io/hpestorage/csi-extensions:v1.2.7-beta
    imagePullPolicy: IfNotPresent
    name: csi-extensions
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/lib/csi/sockets/pluginproxy/
      name: socket-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-djh9g
      readOnly: true
  dnsConfig:
    options:
    - name: ndots
      value: "1"
  dnsPolicy: ClusterFirstWithHostNet
  enableServiceLinks: true
  hostNetwork: true
  nodeName: talos-nvj-4af
  preemptionPolicy: PreemptLowerPriority
  priority:<PHONE_NUMBER>
  priorityClassName: system-cluster-critical
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: hpe-csi-controller-sa
  serviceAccountName: hpe-csi-controller-sa
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - emptyDir: {}
    name: socket-dir
  - hostPath:
      path: /var/log
      type: ""
    name: log-dir
  - hostPath:
      path: /etc/kubernetes
      type: ""
    name: k8s
  - hostPath:
      path: /etc/hpe-storage
      type: ""
    name: hpeconfig
  - hostPath:
      path: /
      type: ""
    name: root-dir
  - name: kube-api-access-djh9g
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:42:41Z"
    status: "True"
    type: PodReadyToStartContainers
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:42:39Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:42:39Z"
    message: 'containers with unready status: [hpe-csi-driver]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:42:39Z"
    message: 'containers with unready status: [hpe-csi-driver]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2024-06-21T18:42:39Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://69d077a9414b9f622fffc550c68bf651c4ede0fc41ef85279347c363049f4f54
    image: registry.k8s.io/sig-storage/csi-attacher:v4.5.1
    imageID: registry.k8s.io/sig-storage/csi-attacher@sha256:9dcd469f02bbb7592ad61b0f848ec242f9ea2102187a0cd8407df33c2d633e9c
    lastState:
      terminated:
        containerID: containerd://dd726dccda8c6a3774e1e96060d9b1529dfebbed83667ea76e6fd85c0b995b0b
        exitCode: 1
        finishedAt: "2024-06-21T18:43:41Z"
        reason: Error
        startedAt: "2024-06-21T18:43:10Z"
    name: csi-attacher
    ready: true
    restartCount: 2
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:43:56Z"
  - containerID: containerd://ab469a79652fd7d894e15f93528d2d92a03fa867c80f818c2575eee3ce530652
    image: quay.io/hpestorage/csi-extensions:v1.2.7-beta
    imageID: quay.io/hpestorage/csi-extensions@sha256:106637da1dad32a0ffda17f3110f5d396cc6b03ed2af63b4c5260c8ed02b1314
    lastState: {}
    name: csi-extensions
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:42:40Z"
  - containerID: containerd://b0a981a751c5143813a4db0b53bb2c2243312136e543a4d65b952dc61b84f5c1
    image: registry.k8s.io/sig-storage/csi-provisioner:v4.0.1
    imageID: registry.k8s.io/sig-storage/csi-provisioner@sha256:bf5a235b67d8aea00f5b8ec24d384a2480e1017d5458d8a63b361e9eeb1608a9
    lastState:
      terminated:
        containerID: containerd://443bb47ec3cb0e9093342377d75f7812422e7f62bf4d0ce5d22757c42052dc15
        exitCode: 1
        finishedAt: "2024-06-21T18:43:40Z"
        reason: Error
        startedAt: "2024-06-21T18:43:10Z"
    name: csi-provisioner
    ready: true
    restartCount: 2
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:43:56Z"
  - containerID: containerd://bbaafc9a87726f13ca40e7b7f1973e4473dd8ce94a78c9a67ce05b7205e88553
    image: registry.k8s.io/sig-storage/csi-resizer:v1.10.1
    imageID: registry.k8s.io/sig-storage/csi-resizer@sha256:4ecda2818f6d88a8f217babd459fdac31588f85581aa95ac7092bb0471ff8541
    lastState:
      terminated:
        containerID: containerd://9d299091598a0a53213d7a92321f4ef5fc9fff1d1f88beba87b62fe35c7b7639
        exitCode: 1
        finishedAt: "2024-06-21T18:43:41Z"
        reason: Error
        startedAt: "2024-06-21T18:43:11Z"
    name: csi-resizer
    ready: true
    restartCount: 2
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:43:56Z"
  - containerID: containerd://fe753c0bc4d762a861c59f5d557c4152e6bf85bb5495fb336e3e8a8ce57bf5e4
    image: registry.k8s.io/sig-storage/csi-snapshotter:v7.0.2
    imageID: registry.k8s.io/sig-storage/csi-snapshotter@sha256:c4b6b02737bc24906fcce57fe6626d1a36cb2b91baa971af2a5e5a919093c34e
    lastState:
      terminated:
        containerID: containerd://ec7b4e064f648cfd70c882b81a601db820d1eaf483f30867bcaaf93347d26879
        exitCode: 1
        finishedAt: "2024-06-21T18:43:41Z"
        reason: Error
        startedAt: "2024-06-21T18:43:11Z"
    name: csi-snapshotter
    ready: true
    restartCount: 2
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:43:56Z"
  - containerID: containerd://1eb157a1a0fe1ebf3bc26ac8a6d7ee1a729fc1e1f7b04edc78664ea1294ceff0
    image: quay.io/hpestorage/volume-group-provisioner:v1.0.6-beta
    imageID: quay.io/hpestorage/volume-group-provisioner@sha256:8d1ee0f752271148c019bc6ff2db53fdbfb56dfce3ede2e8f1549952becfeb05
    lastState: {}
    name: csi-volume-group-provisioner
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:42:40Z"
  - containerID: containerd://42fec0266f3669000d461c690cc2c0fd74e7d8a5c0f0093a5b591c82fc3b6612
    image: quay.io/hpestorage/volume-group-snapshotter:v1.0.6-beta
    imageID: quay.io/hpestorage/volume-group-snapshotter@sha256:9be38de0f93f6b4ce7d0456eaabf5da3890b094a89a7b811852d31fbaf76c79c
    lastState: {}
    name: csi-volume-group-snapshotter
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:42:40Z"
  - containerID: containerd://ae0dce20062d444aa8a124fe753bcc200c1b8008a3a4ef800e7b4500fc73b861
    image: quay.io/hpestorage/volume-mutator:v1.3.6-beta
    imageID: quay.io/hpestorage/volume-mutator@sha256:247153bb789805c272b76fd8018ccd0f8bf4eabded5d4baf362d8a2c162b8672
    lastState: {}
    name: csi-volume-mutator
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-06-21T18:42:40Z"
  - image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imageID: ""
    lastState: {}
    name: hpe-csi-driver
    ready: false
    restartCount: 0
    started: false
    state:
      waiting:
        message: 'failed to generate container "ee110797b0f68f31aa64c448b04f663590359bc4181a08be4f764f4dd599941f"
          spec: failed to generate spec: failed to mkdir "/etc/hpe-storage": mkdir
          /etc/hpe-storage: read-only file system'
        reason: CreateContainerError
  hostIP: <IP_ADDRESS>
  hostIPs:
  - ip: <IP_ADDRESS>
  phase: Pending
  podIP: <IP_ADDRESS>
  podIPs:
  - ip: <IP_ADDRESS>
  qosClass: Burstable
  startTime: "2024-06-21T18:42:39Z"

Ok, I had a brain fart, try now.
helm uninstall my-hpe-csi-driver -nhpe-storage
helm repo update
helm install my-hpe-csi-driver -nhpe-storage datamattsson/hpe-csi-driver --version 2.5.0-talos2 --set disableNodeConfiguration=true

Getting closer, the controller started fine but the hpe-csi-node daemonset pod is still trying to mount /etc/systemd/system
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  2m2s                default-scheduler  Successfully assigned hpe-storage/hpe-csi-node-qv9xk to talos-nvj-4af
  Warning  Failed     2m2s                kubelet            Error: failed to generate container "28b5218a6cea8f05806ec4210312762aa45cc1a851befe51d3e231bb6ff95fa2" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     2m2s                kubelet            Error: failed to generate container "5f4e20edc65d2a0990d99c0b5da15cf61f3c0273d577f1bacacbbcc49bf77ff5" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     108s                kubelet            Error: failed to generate container "1a59382b30bcc28fca08f6b48cf9ccce5adee2d003634ab00a59c9d470ad0a3c" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     97s                 kubelet            Error: failed to generate container "bdcdb9ac2dac778320a6f1fccfa7e0198ceb9f62cce3ab03ca59b7f061442133" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     85s                 kubelet            Error: failed to generate container "97701cc024c101137235529d83b03f1461e1dd97e48c543ac5d72474362e739d" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     74s                 kubelet            Error: failed to generate container "3176d754668a42fc845d93ef4ca8b116bd59f67ec35983626e9901f70099b219" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     61s                 kubelet            Error: failed to generate container "e0d1cee086f4f574cf0e9eee92da6ba94dbaa359990e92068ec6926dd8e16d03" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     46s                 kubelet            Error: failed to generate container "f6ab37bf1edc712984ff69f9f5da848a5eb6e4cf1bec0efa8cc697cc4f776e8b" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Warning  Failed     34s                 kubelet            Error: failed to generate container "c641f39c98980fccbac986b9c4bf7d35b2b226fc70fc12e71c54dc50b672bd77" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system
  Normal   Pulled     7s (x11 over 2m2s)  kubelet            Container image "quay.io/hpestorage/csi-driver:v2.5.0-beta" already present on machine
  Warning  Failed     7s (x2 over 21s)    kubelet            (combined from similar events): Error: failed to generate container "6d45577bdd7ca1971a3eba9b3c110ea41001ed5d08cdfb91792fac458da31a37" spec: failed to generate spec: failed to mkdir "/etc/systemd/system": mkdir /etc/systemd: read-only file system

I did ensure disableNodeConfiguration is set
❯ helm get values my-hpe-csi-driver
USER-SUPPLIED VALUES:
disableNodeConfiguration: true

Ok, I here's the next one. 2.5.0-talos3
helm uninstall my-hpe-csi-driver -nhpe-storage
helm repo update
helm install my-hpe-csi-driver -nhpe-storage datamattsson/hpe-csi-driver --version 2.5.0-talos3 --set disableNodeConfiguration=true

The pod starts but the initContainer immediately crashes
hpe-csi-node-init + '[' --endpoint=unix:///csi/csi.sock = --node-init ']'
hpe-csi-node-init + for arg in "$@"
hpe-csi-node-init + '[' --flavor=kubernetes = --node-service ']'
hpe-csi-node-init + '[' --flavor=kubernetes = --node-init ']'
hpe-csi-node-init + disableNodeConformance=
hpe-csi-node-init + disableNodeConfiguration=
hpe-csi-node-init + '[' true = true ']'
hpe-csi-node-init + '[' '' = true ']'
hpe-csi-node-init + '[' '' = true ']'
hpe-csi-node-init + '[' '' '!=' true ']'
hpe-csi-node-init + cp -f /opt/hpe-storage/lib/hpe-storage-node.service /etc/systemd/system/hpe-storage-node.service
hpe-csi-node-init + cp -f /opt/hpe-storage/lib/hpe-storage-node.sh /etc/hpe-storage/hpe-storage-node.sh
hpe-csi-node-init cp: cannot create regular file '/etc/hpe-storage/hpe-storage-node.sh': No such file or directory

I looks like the DISABLE_NODE_CONFIGURATION environment variable is not getting set on the initContainer
spec:
    containers:
  - args:
    - --csi-address=$(ADDRESS)
    - --kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)
    - --v=5
    env:
    - name: ADDRESS
      value: /csi/csi.sock
    - name: DRIVER_REG_SOCK_PATH
      value: /var/lib/kubelet/plugins/csi.hpe.com/csi.sock
    - name: KUBE_NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName
    image: registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.1
    imagePullPolicy: IfNotPresent
    name: csi-node-driver-registrar
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /csi
      name: plugin-dir
    - mountPath: /registration
      name: registration-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-xsr7w
      readOnly: true
  - args:
    - --endpoint=$(CSI_ENDPOINT)
    - --node-service
    - --flavor=kubernetes
    - --node-monitor
    - --node-monitor-interval=30
    env:
    - name: CSI_ENDPOINT
      value: unix:///csi/csi.sock
    - name: LOG_LEVEL
      value: info
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: spec.nodeName
    - name: DISABLE_NODE_CONFIGURATION
      value: "true"
    - name: KUBELET_ROOT_DIR
      value: /var/lib/kubelet
    image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imagePullPolicy: IfNotPresent
    name: hpe-csi-driver
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        add:
        - SYS_ADMIN
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /csi
      name: plugin-dir
    - mountPath: /var/lib/kubelet
      mountPropagation: Bidirectional
      name: pods-mount-dir
    - mountPath: /host
      mountPropagation: Bidirectional
      name: root-dir
    - mountPath: /dev
      name: device-dir
    - mountPath: /var/log
      name: log-dir
    - mountPath: /etc/kubernetes
      name: etc-kubernetes
    - mountPath: /sys
      name: sys
    - mountPath: /run/systemd
      name: runsystemd
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-xsr7w
      readOnly: true
  dnsConfig:
    options:
    - name: ndots
      value: "1"
  dnsPolicy: ClusterFirstWithHostNet
  enableServiceLinks: true
  hostNetwork: true
  initContainers:
  - args:
    - --node-init
    - --endpoint=$(CSI_ENDPOINT)
    - --flavor=kubernetes
    env:
    - name: CSI_ENDPOINT
      value: unix:///csi/csi.sock
    image: quay.io/hpestorage/csi-driver:v2.5.0-beta
    imagePullPolicy: IfNotPresent
    name: hpe-csi-node-init
    resources:
      limits:
        cpu: "2"
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 128Mi
    securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        add:
        - SYS_ADMIN
      privileged: true
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /host
      mountPropagation: Bidirectional
      name: root-dir
    - mountPath: /dev
      name: device-dir
    - mountPath: /sys
      name: sys
    - mountPath: /run/systemd
      name: runsystemd
    - mountPath: /csi
      name: plugin-dir
    - mountPath: /var/lib/kubelet
      name: pods-mount-dir
    - mountPath: /var/log
      name: log-dir
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-xsr7w
      readOnly: true

This is very interesting, I think you just uncovered a different bug altogether. =)

Ok, talos4 has been published.
helm uninstall my-hpe-csi-driver -nhpe-storage
helm repo update
helm install my-hpe-csi-driver -nhpe-storage datamattsson/hpe-csi-driver --version 2.5.0-talos3 --set disableNodeConfiguration=true

I edited the DS to add the environment variable. The initContainer succeeds now but then I think we get to meat of the situation the csi-node-driver-registrar starts crashing and the hpe-csi-driver container complains it can't find initiators. It looks like part of the problem is on the Talos Side their iscsi-tools extension doesn't appear to include the multipath command https://github.com/siderolabs/extensions/issues/134. Though democratic-csi claims that it's not needed I'm not an expert in iSCSI so I can't say how true https://github.com/democratic-csi/democratic-csi/pull/225#issuecomment-1478699681
Container logs
hpe-csi-driver + '[' --endpoint=unix:///csi/csi.sock = --node-service ']'
hpe-csi-driver + '[' --endpoint=unix:///csi/csi.sock = --node-init ']'
csi-node-driver-registrar I0621 21:31:10.477623       1 main.go:157] Attempting to open a gRPC connection with: "/csi/csi.sock"
csi-node-driver-registrar I0621 21:31:10.477723       1 connection.go:215] Connecting to unix:///csi/csi.sock
csi-node-driver-registrar I0621 21:31:10.478469       1 main.go:164] Calling CSI driver to discover driver name
hpe-csi-driver + for arg in "$@"
hpe-csi-driver + '[' --node-service = --node-service ']'
hpe-csi-driver + nodeService=true
hpe-csi-driver + '[' --node-service = --node-init ']'
hpe-csi-driver + for arg in "$@"
hpe-csi-node-init + for arg in "$@"
hpe-csi-node-init + '[' --endpoint=unix:///csi/csi.sock = --node-service ']'
hpe-csi-node-init + '[' --endpoint=unix:///csi/csi.sock = --node-init ']'
hpe-csi-node-init + for arg in "$@"
hpe-csi-node-init + '[' --flavor=kubernetes = --node-service ']'
hpe-csi-node-init + '[' --flavor=kubernetes = --node-init ']'
hpe-csi-node-init + disableNodeConformance=
hpe-csi-node-init + disableNodeConfiguration=true
hpe-csi-node-init + '[' true = true ']'
hpe-csi-node-init + '[' '' = true ']'
csi-node-driver-registrar I0621 21:31:10.478557       1 connection.go:244] GRPC call: /csi.v1.Identity/GetPluginInfo
csi-node-driver-registrar I0621 21:31:10.478586       1 connection.go:245] GRPC request: {}
csi-node-driver-registrar I0621 21:31:10.481052       1 connection.go:251] GRPC response: {"name":"csi.hpe.com","vendor_version":"1.3"}
csi-node-driver-registrar I0621 21:31:10.481063       1 connection.go:252] GRPC error: <nil>
hpe-csi-node-init + '[' true = true ']'
hpe-csi-node-init + echo 'Node configuration is disabled'
hpe-csi-node-init + disableConformanceCheck=true
hpe-csi-node-init + '[' true '!=' true ']'
hpe-csi-node-init + exec /bin/csi-driver --node-init --endpoint=unix:///csi/csi.sock --flavor=kubernetes
hpe-csi-node-init Node configuration is disabled
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=info msg="Initialized logging." alsoLogToStderr=true logFileLocation=/var/log/hpe-csi-controller.log logLevel=info
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=info msg="**********************************************" file="csi-driver.go:56"
hpe-csi-driver + '[' --flavor=kubernetes = --node-service ']'
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=info msg="*************** HPE CSI DRIVER ***************" file="csi-driver.go:57"
hpe-csi-driver + '[' --flavor=kubernetes = --node-init ']'
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=info msg="**********************************************" file="csi-driver.go:58"
hpe-csi-driver + for arg in "$@"
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=info msg=">>>>> CMDLINE Exec, args: ]" file="csi-driver.go:60"
hpe-csi-driver + '[' --node-monitor = --node-service ']'
hpe-csi-node-init W0621 21:31:06.910459       1 reflector.go:424] hpe-csi-driver/pkg/flavor/kubernetes/flavor.go:145: failed to list *v1.VolumeSnapshot: volumesnapshots.snapshot.storage.k8s.io is forbidden: User "system:serviceaccount:hpe-storage:hpe-csi-node-sa" cannot list resource "volumesnapshots" in API group "snapshot.storage.k8s.io" at the cluster scope
hpe-csi-driver + '[' --node-monitor = --node-init ']'
hpe-csi-driver + for arg in "$@"
hpe-csi-driver + '[' --node-monitor-interval=30 = --node-service ']'
hpe-csi-driver + '[' --node-monitor-interval=30 = --node-init ']'
hpe-csi-driver + disableNodeConformance=
hpe-csi-driver + disableNodeConfiguration=true
hpe-csi-driver + '[' '' = true ']'
hpe-csi-driver + '[' true = true ']'
hpe-csi-driver + echo 'copying hpe log collector diag script'
hpe-csi-driver copying hpe log collector diag script
hpe-csi-driver + cp -f /opt/hpe-storage/bin/hpe-logcollector.sh /usr/local/bin/hpe-logcollector.sh
hpe-csi-driver + chmod +x /usr/local/bin/hpe-logcollector.sh
hpe-csi-driver + '[' '!' -f /host/etc/multipath.conf ']'
hpe-csi-driver + '[' true '!=' true ']'
hpe-csi-driver + ln -s /host/etc/multipath.conf /etc/multipath.conf
hpe-csi-driver + ln -s /host/etc/multipath /etc/multipath
hpe-csi-driver + ln -s /host/etc/iscsi /etc/iscsi
hpe-csi-driver + '[' -f /host/etc/redhat-release ']'
hpe-csi-driver + '[' -f /host/etc/os-release ']'
hpe-csi-driver + rm /etc/os-release
csi-node-driver-registrar I0621 21:31:10.481070       1 main.go:173] CSI driver name: "csi.hpe.com"
csi-node-driver-registrar I0621 21:31:10.481110       1 node_register.go:55] Starting Registration Server at: /registration/csi.hpe.com-reg.sock
csi-node-driver-registrar I0621 21:31:10.481557       1 node_register.go:64] Registration Server started at: /registration/csi.hpe.com-reg.sock
csi-node-driver-registrar I0621 21:31:10.481696       1 node_register.go:88] Skipping HTTP server because endpoint is set to: ""
csi-node-driver-registrar I0621 21:31:11.759238       1 main.go:90] Received GetInfo call: &InfoRequest{}
csi-node-driver-registrar I0621 21:31:11.777891       1 main.go:101] Received NotifyRegistrationStatus call: &RegistrationStatus{PluginRegistered:false,Error:RegisterPlugin error -- plugin registration failed with err: rpc error: code = Internal desc = Failed to get initiators for host,}
csi-node-driver-registrar E0621 21:31:11.778006       1 main.go:103] Registration process failed with error: RegisterPlugin error -- plugin registration failed with err: rpc error: code = Internal desc = Failed to get initiators for host, restarting registration container.
hpe-csi-node-init E0621 21:31:06.910696       1 reflector.go:140] hpe-csi-driver/pkg/flavor/kubernetes/flavor.go:145: Failed to watch *v1.VolumeSnapshot: failed to list *v1.VolumeSnapshot: volumesnapshots.snapshot.storage.k8s.io is forbidden: User "system:serviceaccount:hpe-storage:hpe-csi-node-sa" cannot list resource "volumesnapshots" in API group "snapshot.storage.k8s.io" at the cluster scope
hpe-csi-node-init E0621 21:31:06.910770       1 reflector.go:140] hpe-csi-driver/pkg/flavor/kubernetes/flavor.go:127: Failed to watch *v1.PersistentVolumeClaim: unknown (get persistentvolumeclaims)
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=error msg="process with pid : 11 finished with error = exit status 127" file="cmd.go:63"
hpe-csi-node-init time="2024-06-21T21:31:06Z" level=error msg="Error while getting the multipath devices on the node " file="utils.go:11"
hpe-csi-driver + ln -s /host/etc/os-release /etc/os-release
hpe-csi-driver + echo 'starting csi plugin...'
hpe-csi-driver + exec /bin/csi-driver --endpoint=unix:///csi/csi.sock --node-service --flavor=kubernetes --node-monitor --node-monitor-interval=30
hpe-csi-driver starting csi plugin...
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Initialized logging." alsoLogToStderr=true logFileLocation=/var/log/hpe-csi-node.log logLevel=info
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="**********************************************" file="csi-driver.go:56"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="*************** HPE CSI DRIVER ***************" file="csi-driver.go:57"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="**********************************************" file="csi-driver.go:58"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg=">>>>> CMDLINE Exec, args: ]" file="csi-driver.go:60"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Node configuration is disabled, DISABLE_NODE_CONFIGURATION=true.Skipping the Multipath and ISCSI configurations" file="csi-driver.go:142"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="NODE MONITOR: &{flavor:0xc0001f4d10 intervalSec:30 lock:{state:0 sema:0} started:false stopChannel:<nil> done:<nil> nodeName:talos-nvj-4af}" file="nodemonitor.go:26"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: CREATE_DELETE_VOLUME" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: PUBLISH_UNPUBLISH_VOLUME" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: LIST_VOLUMES" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: CREATE_DELETE_SNAPSHOT" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: LIST_SNAPSHOTS" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: CLONE_VOLUME" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: PUBLISH_READONLY" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling controller service capability: EXPAND_VOLUME" file="driver.go:250"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling node service capability: STAGE_UNSTAGE_VOLUME" file="driver.go:267"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling node service capability: EXPAND_VOLUME" file="driver.go:267"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling node service capability: GET_VOLUME_STATS" file="driver.go:267"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling volume expansion type: ONLINE" file="driver.go:281"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling volume access mode: SINGLE_NODE_WRITER" file="driver.go:293"
Stream closed EOF for hpe-storage/hpe-csi-node-pn769 (csi-node-driver-registrar)
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling volume access mode: SINGLE_NODE_READER_ONLY" file="driver.go:293"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling volume access mode: MULTI_NODE_READER_ONLY" file="driver.go:293"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling volume access mode: MULTI_NODE_SINGLE_WRITER" file="driver.go:293"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Enabling volume access mode: MULTI_NODE_MULTI_WRITER" file="driver.go:293"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="DB service disabled!!!" file="driver.go:145"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="About to start the CSI driver 'csi.hpe.com with KubeletRootDirectory /var/lib/kubelet/'" file="csi-driver.go:186"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="[1] reply  : [/bin/csi-driver --endpoint=unix:///csi/csi.sock --node-service --flavor=kubernetes --node-monitor --node-monitor-interval=30]" file="csi-driver.go:189"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Listening for connections on address: &net.UnixAddr{Name:\"//csi/csi.sock\", Net:\"unix\"}" file="server.go:86"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="Scheduled ephemeral inline volumes scrubber task to run every 3600 seconds, PodsDirPath: [/var/lib/kubelet/pods]" file="driver.go:214"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg=">>>>> Scrubber task invoked at 2024-06-21 21:31:07.639939957 +0000 UTC m=+0.038113292" file="driver.go:746"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="No ephemeral inline volumes found" file="driver.go:815"
hpe-csi-driver time="2024-06-21T21:31:07Z" level=info msg="<<<<< Scrubber task completed at 2024-06-21 21:31:07.644313576 +0000 UTC m=+0.042486921" file="driver.go:751"
hpe-csi-driver time="2024-06-21T21:31:08Z" level=info msg="GRPC call: /csi.v1.Identity/GetPluginInfo" file="utils.go:69"
hpe-csi-driver time="2024-06-21T21:31:08Z" level=info msg="GRPC request: {}" file="utils.go:70"
hpe-csi-driver time="2024-06-21T21:31:08Z" level=info msg=">>>>> GetPluginInfo" file="identity_server.go:16"
hpe-csi-driver time="2024-06-21T21:31:08Z" level=info msg="<<<<< GetPluginInfo" file="identity_server.go:19"
hpe-csi-driver time="2024-06-21T21:31:08Z" level=info msg="GRPC response: {\"name\":\"csi.hpe.com\",\"vendor_version\":\"1.3\"}" file="utils.go:75"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=info msg="GRPC call: /csi.v1.Node/NodeGetInfo" file="utils.go:69"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=info msg="GRPC request: {}" file="utils.go:70"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=info msg="Writing uuid to file:/etc/hpe-storage/node.gob uuid:fb4b2815-d7b3-8e09-bf95-39eb01fb29ed" file="chapidriver_linux.go:52"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=error msg="process with pid : 20 finished with error = exit status 127" file="cmd.go:63"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=info msg="Host name reported as talos-nvj-4af" file="node_server.go:2087"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=warning msg="no fc adapters found on the host" file="fc.go:49"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=error msg="Failed to get initiators for host talos-nvj-4af.  Error: iscsi and fc initiators not found" file="node_server.go:2091"
hpe-csi-driver time="2024-06-21T21:31:09Z" level=error msg="GRPC error: rpc error: code = Internal desc = Failed to get initiators for host" file="utils.go:73"
hpe-csi-driver time="2024-06-21T21:31:10Z" level=info msg="GRPC call: /csi.v1.Identity/GetPluginInfo" file="utils.go:69"
hpe-csi-driver time="2024-06-21T21:31:10Z" level=info msg="GRPC request: {}" file="utils.go:70"
hpe-csi-driver time="2024-06-21T21:31:10Z" level=info msg=">>>>> GetPluginInfo" file="identity_server.go:16"
hpe-csi-driver time="2024-06-21T21:31:10Z" level=info msg="<<<<< GetPluginInfo" file="identity_server.go:19"
hpe-csi-driver time="2024-06-21T21:31:10Z" level=info msg="GRPC response: {\"name\":\"csi.hpe.com\",\"vendor_version\":\"1.3\"}" file="utils.go:75"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=info msg="GRPC call: /csi.v1.Node/NodeGetInfo" file="utils.go:69"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=info msg="GRPC request: {}" file="utils.go:70"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=info msg="Host name reported as talos-nvj-4af" file="node_server.go:2087"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=warning msg="no fc adapters found on the host" file="fc.go:49"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=error msg="process with pid : 23 finished with error = exit status 127" file="cmd.go:63"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=error msg="Failed to get initiators for host talos-nvj-4af.  Error: iscsi and fc initiators not found" file="node_server.go:2091"
hpe-csi-driver time="2024-06-21T21:31:11Z" level=error msg="GRPC error: rpc error: code = Internal desc = Failed to get initiators for host" file="utils.go:73"
Stream closed EOF for hpe-storage/hpe-csi-node-pn769 (hpe-csi-node-init)

Not sure how much help it is, but looking at your code it looks like perhaps the main issue is you're looking for the /etc/iscsi/initiatorname.iscsi file but that file doesn't exist in the normal placed in their system. Their extension bind mounts /usr/local/etc/iscsi/iscsid.con into the extension container at /etc/iscsi/iscsid.conf https://github.com/siderolabs/extensions/blob/f0b6082466dc78a309d1e9a7d8525497d714d4d4/storage/iscsi-tools/iscsid.yaml#L52C5-L53C42 but it doesn't mount the rest of the iSCSI folder so the initiator name is not accessible to you.
Looks to me like they need to mount the full /usr/local/etc/iscsi directory so that your driver can access that file, I assume that's how you get the imitator to register with the storage.

EUREKA! I found it they do mount the /etc/iscsi directory into /system/iscsi on the host, I shelled into the hpe-csi-node/hpe-csi-driver container and changed the link from /etc/iscsi -> /host/etc/iscsi to /host/system/iscsi when the registrar next restarted the driver container was able to find the initiator name and everything is now running.
❯ k get pods
NAME                                  READY   STATUS    RESTARTS        AGE
hpe-csi-controller-8447c48d9f-rjd49   9/9     Running   0               22m
hpe-csi-node-5t69x                    2/2     Running   9 (5m45s ago)   22m
nimble-csp-74776998b6-fmcn2           1/1     Running   0               22m
primera3par-csp-58dd48cccb-lvvjb      1/1     Running   0               22m

obviously that will break when that pod restarts. But I then created a storage class and a PVC and it worked right away
❯ k get pvc
NAME           STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS     VOLUMEATTRIBUTESCLASS   AGE
my-first-pvc   Bound    pvc-dc881628-ffe4-42c9-951e-e266502dd226   32Gi       RWO            csq-it-nimble1   <unset>                 2m5s

and I can see the volume on the array.
The last step mounting it is the one remaining issue. It does not successfully mount the volume. That appears to actually be related to the multipath I mentioned. I'm signing off for the weekend I'll look more on Monday

I should've researched this but is /usr/local/etc writable in Talos? (or, what directory IS writable and/or persistent on Talos?) I'm thinking we could just add a Helm chart parameter for CSI driver users to relocate /etc to whatever directory on the node.
As for commands the CSI driver needs to have availabe, look for clues here: https://github.com/hpe-storage/csi-driver/blob/master/Dockerfile
As for the multipath issue is that the HPE CSI Driver require multipath/multipathd on the host, there's no workaround as we don't even consider non-multipath entries.
I'm out of pocket of the rest of the weekend as well, cheers!

I've exhausted the time I can work on this for now. But this is what I found messing around some more. Hopefully it can help you get on the correct path, but it certainly looks like it's going to require more work than just changing the mount location. It does give me a little better idea on my planning though, I'll probably need to plan on a longer time for support.
It looks like /system is supposed to be the location for "persistent" data but it appears they mean persistent for the extension container lifecycle. The data is persistent if you restart the extension but it is not persistent over reboots. The path /system/state which contains the node config is persistent, and /var which is used as the storage for container images is persistent across reboots but I believe is not guaranteed.
However because the extensions are not persistent across reboots things like the Initiator name are not consistent, a new one is generated on every boot. Because of this I don't think it's a good idea to try and persist your node ID on disk like we discussed earlier. Either that should be generated dynamically or use the Kubernetes Node ID and store extra persistent data in a configmap or crd. In my opinion this is more in line with the general idea of Kubernetes anyway and cattle vs pets workflows.
Overall I see two maybe three major problems. One will require changes from Talos, the other will require work on your driver

Their iscsi-tools extension doesn't include multipath support, as I mentioned above. I've commented on their ticket hopefully we can get some attention from them.
Because the iscsi-tools runs as an OS level container it also has a very limited subset of tools. I was able to get iscsiadm to work by changing the chroot script to use nsenter instead, though maybe it would work without using env.

#!/bin/bash

iscsi_pid=$(pgrep -f "iscsid -f")

nsenter --mount="/proc/$iscsi_pid/ns/mnt" --net="/proc/$iscsi_pid/ns/net" -- /usr/local/sbin/iscsiadm "${@:1}"

You may have to use your own binaries for some operations and/or limit FS support to just XFS with Talos. The host system has binaries for xfs and vfat, but no mount or ext4/btrfs binaries. Here's all the binaries available on the host, note the iscsi one come from the iscsi-tools. Here's a dump of all the available binaries on the host, this includes the ones from the iscsi-tools extension

/ # find /host -name "*bin" -type d 2>/dev/null | grep -v var | grep -v container | xargs ls
/host/bin:
containerd               containerd-shim-runc-v2
containerd-shim          runc

/host/opt/cni/bin:
bandwidth    firewall     ipvlan       ptp          tuning
bridge       flannel      loopback     sbr          vlan
dhcp         host-device  macvlan      static       vrf
dummy        host-local   portmap      tap

/host/sbin:
blkdeactivate             lvm                       udevadm
dashboard                 lvm_import_vdo            udevd
dmsetup                   lvmconfig                 vgcfgbackup
dmstats                   lvmdevices                vgcfgrestore
dmstats.static            lvmdiskscan               vgchange
fsadm                     lvmdump                   vgck
fsck.xfs                  lvmsadc                   vgconvert
init                      lvmsar                    vgcreate
ip6tables                 lvreduce                  vgdisplay
ip6tables-apply           lvremove                  vgexport
ip6tables-legacy          lvrename                  vgextend
ip6tables-legacy-restore  lvresize                  vgimport
ip6tables-legacy-save     lvs                       vgimportclone
ip6tables-restore         lvscan                    vgimportdevices
ip6tables-save            mkfs.xfs                  vgmerge
iptables                  modprobe                  vgmknodes
iptables-apply            poweroff                  vgreduce
iptables-legacy           pvchange                  vgremove
iptables-legacy-restore   pvck                      vgrename
iptables-legacy-save      pvcreate                  vgs
iptables-restore          pvdisplay                 vgscan
iptables-save             pvmove                    vgsplit
lvchange                  pvremove                  wrapperd
lvconvert                 pvresize                  xfs_repair
lvcreate                  pvs                       xtables-legacy-multi
lvdisplay                 pvscan
lvextend                  shutdown

/host/usr/bin:
udevadm

/host/usr/local/bin:

/host/usr/local/sbin:
brcm_iscsiuio            iscsi_offload            iscsiuio
iscsi-gen-initiatorname  iscsiadm                 tgtadm
iscsi-iname              iscsid                   tgtd
iscsi_discovery          iscsid-wrapper           tgtimg
iscsi_fw_login           iscsistart

/host/usr/sbin:
cryptsetup      mkfs.fat        xfs_freeze      xfs_ncheck
dosfsck         mkfs.msdos      xfs_fsr         xfs_quota
dosfslabel      mkfs.vfat       xfs_growfs      xfs_rtcp
fatlabel        veritysetup     xfs_info        xfs_scrub
fsck.fat        xfs_admin       xfs_io          xfs_scrub_all
fsck.msdos      xfs_bmap        xfs_logprint    xfs_spaceman
fsck.vfat       xfs_copy        xfs_mdrestore
integritysetup  xfs_db          xfs_metadump
mkdosfs         xfs_estimate    xfs_mkfile

Thanks for the additional context. This definitely needs more work. I'm just puzzled how we can't even persist an IQN on the host though? Do we need to grab the first boot one and store in our CRD and regenerate the host IQN from that?
I guess FC wouldn't have as many problems but we still would need multipath/multipathd regardless. Not having ext4 available will also create problems for our NFS server implementation for RWX claims that doesn't play nicely with XFS in failure scenarios.

Thanks for the additional context. This definitely needs more work. I'm just puzzled how we can't even persist an IQN on the host though? Do we need to grab the first boot one and store in our CRD and regenerate the host IQN from that?
It doesn't look like you can manage the IQN, their service generates one itself.

Just my thoughts I can think of two ways to deal with it

Don't care about it. Have the controller only add an IQN to the array when needed and remove when not needed. So for example you are running a DB on a node with a PV but then you drain the node so the DB gets rescheduled on a different node and the old node is no longer needed so the controller removes it from the array. The controller would also keep track of known initiators and occasionally check to see if they are still live in the Kubernetes cluster and remove from the array if not to catch cases where nodes disappear. This would be the cattle/pets option
Use the new ExtensionServiceConfig to specify IQNs, https://www.talos.dev/v1.7/reference/configuration/extensions/extensionserviceconfig/. This would require that Talos add support for it and administrators would have to generate IQNs for their systems which could be error prone.

I guess FC wouldn't have as many problems but we still would need multipath/multipathd regardless. Not having ext4 available will also create problems for our NFS server implementation for RWX claims that doesn't play nicely with XFS in failure scenarios.

Looking around at other CSI iSCSI implementations it looks like many of them use their own mkfs and mount binaries rather than rely on the host

we also need the feature of HPE driver integration with talos, please prioritize this one, thanks


Add comments for fields in the response for nodejs/query endpoint

This came up because Kara is adding documentation about the nodejs/query endpoint & wanted clarification about some of the fields in the response. Thought this information could be useful to have here

thanks for the review!


pkg_manifest: sort before writing to manifest file

Rewriting manifest can be very massive, since find will just get whatever comes in first. Gettext has a long diff in manifest alone. After this commit, I hope we have one last massive manifest diff changes for each package, and the manifest changes will be reserved for the new/deleted file.

:+1:


vCheck reports hardware errors, SEL fullness alerts and memory alerts on ESXi hosts

vCheck reports hardware errors, SEL fullness alerts and memory alerts on ESXi hosts but when I look in the vcenter and also in UCS manager I do not see any alerts or issues with that particular ESXi host. What would be the reason for these alerts? and how can we make vcheck clear these alerts if everything is looking good.

Sometimes, PowerCLI API uses cached data and reports different sensor values than vCenter. There's a KB with more information.
vSphere ESX/ESXi hardware status sensors return different cached values in API than in vSphere Client (1037330)


I tried command form README but yarn is not recognized in my compiler.

@Sylvester-dev if you installed GatsbyJS via npm or yarn, try running gatsby develop

It'll definitely work! :smile:


Deduplication not working

Issue
Issue Type

[x] Bug
[ ] Enhancement

Description
During scan import (burp XML report, retrieved by API), DefectDojo don't operate deduplication about findings. I try to import the same report two times in the same testID and in two different testID. I havealready activated the option deduplicating findings, the option delete duplicate and set the max duplicate to 1.
Background
Operating System
Linux Ubuntu 18?04 LTS - 4.15.0-20 x64.
Install

[x] setup.bash
[ ] docker

DefectDojo Version
I'm running the last version (fresh git pull)
Steps to Reproduce
Try to import  this burp report twice and see that the deduplication process do nothing (all findings are store twice)
reportBurpLight.zip

Make sure that you either have celery running and/or set your user preferences to blocking. If that still doesn't work for you we've made a few patches in dev for certain edge cases.

Everythings works ! Thank you so much.


frame length

is the min frame length for porcupine 512??
using Python3.6 for testing
i have an audio file with a frame length of 256.. and when running porcupine.process on this it never picks up the hotword
the audio stream i am using is
ChunkID= b'RIFF'
TotalSize= 556
DataSize= 512
Format= b'WAVE'
SubChunk1ID= b'fmt '
SubChunk1Size= 16
AudioFormat= 1
NumChannels= 1
SampleRate= 16000
ByteRate= 32000
BlockAlign= 2
BitsPerSample= 16
SubChunk2ID= b'data'
SubChunk2Size= 512

correct. It accepts 512 samples per frame. You can buffer the audio and pass it to engine every other frame.

to make sure im not going mad.. i added pyaudio output
pa = pyaudio.PyAudio()
stream = pa.open(format=pyaudio.paInt16, channels=1, rate=16000, output=True, frames_per_buffer=512)
and just before the
result = porcupine.process(pcm)
i added stream.write(pcm)
i can hear the audio just fine.. nice and clear.. but porcupine does not pick up the hotword (yet as i said above, using the same stream and porcupine code and ppn files etc it does work )

maybe im not understanding samples or frames correctly
so the stream comes in as a wave file.. so when i look at the wav info i get
_wave_params(nchannels=1, sampwidth=2, framerate=16000, nframes=256, comptype='NONE', compname='not compressed')
so i set nFrames = 256
and in code
b = io.BytesIO(msg.payload)
audio = wave.open(b, 'rb').readframes(nFrames)
result = porcupine.process(audio)
and result never fires the hotword being found
thought maybe the audio code is bad.. so added pyAudio to listen to the stream
pa = pyaudio.PyAudio()
stream = pa.open(format=pyaudio.paInt16, channels=1, rate=16000, output=True, frames_per_buffer=nFrames)
and then the code is
b = io.BytesIO(msg.payload)
audio = wave.open(b, 'rb').readframes(nFrames)
stream.write(audio)
result = porcupine.process(audio)
the audio playing is crystal clear so its not bad code converting the audio.. and so added the code print(len(audio)) before the stream write.. it outputs to console 512. 512. 512 ....
so then though as you said porcupine like 512.. so i changed the stream to 512.. and ran again
_wave_params(nchannels=1, sampwidth=2, framerate=16000, nframes=512, comptype='NONE', compname='not compressed')
and changed nFrames = 512
again the audio playing from pyAudio is crystal clear.. now the console logs 1024. 1024. 1024..
but again porcupine never picks up the hotword
any idea what might be wrong? im not sure if the sample width being 2 and nFrames 512 makes the console len print 1024? but with the stream at 256 or 512.. and the len outputting 512 or 1024 porcupine never fires

so i changed using wave to soundfile
replaced the code for opening the wave with
audio, sample_rate = soundfile.read(b, dtype='int16')
the len of audio console prints 512.. good :)
porcupine fires on the hotword.. good :)
pyAudio does not sound good at all.. its all choppy
nFrames = 512
pa = pyaudio.PyAudio()
stream = pa.open(format=pyaudio.paInt16, channels=1, rate=16000, output=True, frames_per_buffer=nFrames)
...
stream.write(audio)
sounds choppy.. not clear like it was using the wave lib to open it.. but porcupine works with soundfile whereas it does not with wave.. using the same code

Could it be an endianness issue?

i have removed wave from the imports and just using soundfile now
everything is working well


ensure _Unwind_Backtrace to actually be available

Codecov Report

Merging #767 (50d7e3f) into master (9dc1107) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #767   +/-   ##
=======================================
  Coverage   72.63%   72.63%
=======================================
  Files          17       17
  Lines        3241     3241
=======================================
  Hits         2354     2354
  Misses        887      887

Impacted Files
Coverage Δ

src/stacktrace_unwind-inl.h
92.85% <ø> (ø)

src/utilities.h
100.00% <ø> (ø)

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 9dc1107...50d7e3f. Read the comment docs.


using pmap with GraphsTuple

Looking at some other code that uses pmap for multigpu, pmapped functions want an additional axis representing the gpus.
GraphsTuple is just an ordered tuple of feature arrays and metadata, where feature arrays are rank 2 and metadata is rank 1. Am I understanding correctly that the way to use multigpu learning here is by having rank 3 and 2 arrays inside GraphsTuple like the following?

take BS * N_GPU graphs from data source
make N_GPU batches via jraph.batch
pad_graphs_to_nearest_power_of_two that handles multiple inputs => now you have equal shaped arrays
create one GraphsTuple with pmappable (rank 3) features
use graphnets with pmapped functions

Hi Sooheon, I'm sorry I haven't got tot this sooner I had somehow missed it.
Good queston! You would have one GraphsTuple with pmappable features.
In psuedocode this would be something like:
batch = []
for _ in range(batch_size):
  batch.append(next(dataset))

# At the moment we have N graphs tuples. We pad each to the same common size.
batch = [pad(el) for el in batch]

batch = jax.tree_multimap(lambda *x: jnp.stack(x, axis=0), *batch)
```

Cool, what I was thinking was along the lines of what you wrote, except the zero axis is the "n_gpus" dim, and each gpu receives a batched graphstuple that's big enough to saturate the memory. Basically the same but each element is already batched with jraph.batch. I wrote the following to pad multiple batches at once to a common dim, would you like a pr for this?
def pad_batch_of_graphs_to_nearest_power_of_two(batch: [jraph.GraphsTuple]) -> [jraph.GraphsTuple]:
  pad_nodes_to = 0
  pad_edges_to = 0
  pad_graphs_to = 0
  for graph in batch:
    n = _nearest_bigger_power_of_two(jnp.sum(graph.n_node)) + 1
    e = _nearest_bigger_power_of_two(jnp.sum(graph.n_edge))
    ng = graph.n_node.shape[0] + 1
    pad_nodes_to = max(pad_nodes_to, n)
    pad_edges_to = max(pad_edges_to, e)
    pad_graphs_to = max(pad_graphs_to, ng)
  return [jraph.pad_with_graphs(g, pad_nodes_to, pad_edges_to, pad_graphs_to)
          for g in batch]

Hey,
Thanks for this! I think the best place for this would probably be in an example, what do you think?
It may be that at a later date we add it to the final library but It's not clear to me we have the final answer for the right way to pad - e.g. I'm not sure that padding to the nearest power of two is always best.

Yeah I could make an extension to one of your OGB examples with working pmap when I find some time.

Yeah I could make an extension to one of your OGB examples with working pmap when I find some time.

@sooheon Did you manage to create that example with OGB?.

Hi Sooheon, I'm sorry I haven't got tot this sooner I had somehow missed it.
Good queston! You would have one GraphsTuple with pmappable features.
In psuedocode this would be something like:
batch = []
for _ in range(batch_size):
  batch.append(next(dataset))

# At the moment we have N graphs tuples. We pad each to the same common size.
batch = [pad(el) for el in batch]

batch = jax.tree_multimap(lambda *x: jnp.stack(x, axis=0), *batch)

When you do  next(dataset), do your dataset loader return one graph or batch of graphs?.
Also, I think this will only work when pad_function gives the same dimensions for all graphs after padding. So padding to the nearest power of two might not always give the same dimensions for all graphs depending on their sizes.
So as @sooheon suggested getting the max for nodes, edges, and graphs makes sense. But also, running a loop for all the batches in a big graph dataset might be inefficient. @jg8610 do you have any resources where they used Jraph with pmap efficiently or any suggestions? Thank you very much.

Hey there,
I wanted to follow up with another suggestion for pmapping, one we use internally, using dynamically_batch.
The first step is to define a budget for your batch. The budget determined the maximum number of nodes, edges and graphs in your batch. This should be set to at least the size of your largest graph in your dataset.
Then, dynamic batching following the following pseudocode:
batch = None
While budget_not_hit:
  jraph.batch(next(dataset), batch)

Once the budget is hit, the batch is padded and returned to the user.
To use this with pmap you would do something like:
batched_dataset = jraph.dynamically_batch(dataset_iterator, n_node=10, n_edge=10, n_graph=2)
# for use with pmap
pmap_batch = []
for _ in range(num_devices):
  pmap_batch.append(next(batched_dataset))

jax.pmap(graph_net)(pmap_batch)


CSS and JS files are not added to Expressive Code blocks

Hello,
I build Astro in SSG with 4.2.3 and Expressive Code 0.32.1.
I was testing the  component again as it brings variable support within code samples.
This works well except in some occurrences when there are multiple code components.
In this case, the CSS and JS files are not added to any code block.
Consider this:
OK

Generated HTML for the code block:

  <link rel="stylesheet" href="/_astro/ec.ksehj.css" />

implementation ("com.contentsquare.android:library:4.24.1") {

    exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib-jdk8"

}

      <button
        title="Copy to clipboard"
        data-copied="Copied!"
        data-code='implementation ("com.contentsquare.android:library:4.24.1") {    exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib-jdk8"}'
      >

      </button>

NOT OK

Generated HTML for the code block:

implementation ("com.contentsquare.android:library:4.24.1") {

    exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib-jdk8"

}

      <button
        title="Copy to clipboard"
        data-copied="Copied!"
        data-code='implementation ("com.contentsquare.android:library:4.24.1") {    exclude group: "org.jetbrains.kotlin", module: "kotlin-stdlib-jdk8"}'
      >

      </button>

The link and script are missing.
I've tried multiple scenarios and it's hard to pinpoint what's the cause.
It seems unrelated to the complexity of the code samples (same with console.log("ok")) or the theme/ec config.

Thank you for reporting this!
I assume that this issue must be related to SSG.
In my code, I'm counting the code blocks I have rendered per Astro.request object, and I only output the link to the styles and scripts for the first code block of each request. In non-SSG mode, this works well and results in every page (which always gets a new Astro.request object) having the styles added to the first block.
Apparently, this logic doesn't work in SSG. I honestly have never tested this with SSG, so I'll need to investigate a better method for counting the code blocks per page. If you have any idea, please let me know!
Is your site repo public so I could just clone it and have a look at the issue locally somehow?

Think that's enough to attest of the issue at hand: https://stackblitz.com/edit/github-tebgdw?file=src%2Fpages%2Findex.astro
Let me know if not!

Ahh. Sorry, I confused SSG with SSR when reading your issue. 🙈
I can also reproduce it locally with your code and will fix and release a patch. Thank you!

Great news! This is more than a quality of life improvement for us 👍

Should be fixed in version 0.32.2. :)

It does work, beautiful.
Makes my day, thank you :-)

Glad to hear that! :) Closing this issue now.


ASUS CN60 UEFIFw: Kodi Freezez after 12Sec

Hi, Asus CN60 ,did the Bios update to UEFI- Thank you for great work. Unfortunately,  video freezes exactly after 12 sec. I'm not sure what info to provide.Kodi-Lbreelec- did all the video upscaling changes etc; reinstalled many times. Please help.I'm not a Linux expert but can do some command line work. Any hints or guidance is much appreciated.Thank you. Dv
putty_1.log

there's nothing in the log to show a problem, need to look at the kodi log file I guess. I've not used LE myself in many years, so your best bet for support is going to be the LE or Kodi forums. Likely a kernel bug or similar.

there's nothing in the log to show a problem, need to look at the kodi log file I guess. I've not used LE myself in many years, so your best bet for support is going to be the LE or Kodi forums. Likely a kernel bug or similar.

Thank you. Will do that.

Closing as not a script issue


Update gatherAADInfo command to no longer point to alias.

The gatherAADInfo command in the Tracking Registration section should be updated to point to the following instead of the alias:
/Library/Application\ Support/JAMF/Jamf.app/Contents/MacOS/Jamf\ Conditional\ Access.app/Contents/MacOS/Jamf\ Conditional\ Access gatherAADInfo

WPJ Key present, AAD ID not acquired
This signifies that the user has a WPJ certificate in their keychain, but jamfAAD has not successfully obtained the Azure AD ID of the user. JamfAAD may try again to grab the AAD ID of the user within the next two hours.
This scenario may also be remediated by running /usr/local/jamf/bin/jamfaad gatherAADInfo on that machine as the logged in user.
Note: If this command is run as root, it will do more harm than good. If running from Jamf Pro, make sure to run it as the logged in user!

Hey @BigKev79 thank you for reporting this! I've updated the document.


Bump formats to a04dcc2a37e43d574eab29dc29c2f45196b1f362

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (main@b425b45). Learn more about missing BASE report.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #228   +/-   ##
=======================================
  Coverage        ?   31.17%
=======================================
  Files           ?        8
  Lines           ?      526
  Branches        ?        0
=======================================
  Hits            ?      164
  Misses          ?      333
  Partials        ?       29

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


ci: collect sysdump as a separate workflow in L4LB tests

Fixes: #18221
Signed-off-by: Ondrej Blazek<EMAIL_ADDRESS>

sysdump collected successfully on failure :heavy_check_mark:  https://github.com/cilium/cilium/actions/runs/1666872689

Thanks @jibi! :pray:

@oblazek @pchaigno @jibi Too late to the party, but shouldn't we have updated tests-l4lb-v1.1{0,1}.yaml too?

Oh, right! Completely forgot about those :facepalm:
@oblazek Could you make the same change to those two other files? They are used to run the workflow on stable branches v1.11 and v1.10.

yes will do ;) sorry, wasn't sure

fix here https://github.com/cilium/cilium/pull/18428


egg_info failure on python venv

Before opening, please confirm:

[X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
[X] I have searched for duplicate or closed issues.
[X] I have read the guide for submitting bug reports.
[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
16.13.1
Amplify CLI Version
7.6.9
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No
Amplify Categories
auth, storage, function, api
Amplify Commands
push
Describe the bug
Suggested configuration for new layer versions:
pbbnt1pandas

Access permissions: Maintain existing permissions
Description: Updated layer version  2022-01-16T21:28:56.636Z

Installing dependencies from Pipfile.lock (e02f68)...
Installing dependencies from Pipfile.lock (e02f68)...
Installing dependencies from Pipfile.lock (e02f68)...
Installing dependencies from Pipfile.lock (e02f68)...
Installing dependencies from Pipfile.lock (571d6c)...
Pipfile.lock not found, creating...
Locking [dev-packages] dependencies...
Locking [packages] dependencies...

Reproduction steps
I'm not sure. Just trying to figure out why it isn't working.
GraphQL schema(s)

# Put schemas below this line

Log output

# Put your logs below this line

Additional information
No response

sudo pip uninstall pip
Apparently there was a conflict with having pip installed.


Mortgage Calculator

Calculate the monthly payments of a fixed term mortgage over given Nth terms at a given interest rate. Also figure out how long it will take the user to pay back the loan. For added complexity, add an option for users to select the compounding interval (Monthly, Weekly, Daily, Continually).


Refactor WorkManager for Hilt dependency injection

Separated the dependencies of Assets and DB previously used in WorkManager and migrated to receive them through Hilt injection. Also, updated the related test code accordingly.

Hi,
Thanks for your contribution, however Sunflower is going to be archived in favour of maintaining a smaller set of up-to-date set of compose-samples, that can be found here: https://github.com/android/compose-samples, as well as snippets that can be found here: https://github.com/android/snippets.
Please feel free to keep your fork up-to-date for your learning, but this repository will be archived shortly.


Packages that expose Rust code with julia_module fail to precompile with Julia 1.10

I haven't debugged this yet, but what seems to be happening is that it's no longer possible to import JlrsCore and mutate the Main module at precompile time.

The big is that you can no longer create constants in other modules (in this case Main) during precompilation. The fix is pretty straightforward:

don't set Main.JlrsCore
use a StaticRef for the reference to JlrsCore in Module::jlrs_core or JlrsCore::module
update code that expects JlrsCore to live Main to use the functions mentioned above

Patch is mostly implementated


Improve owner not found errors

What this PR does / why we need it:
This PR changes the utility function that enqueues the owner of a resource to not error, but instead log an info message if it does not find the owner in the informers cache.
This is to fix a situation where at the time when the controller is started (often after cert-manager upgrade, when folks are watching the logs) owned resources' handlers run before the owners are not yet in cache and cert-manager throws errors.
In the 'certificaterequests' control loop, we watch for changes to Orders and reconcile the owning CertificateRequest. The owning CertificateRequest is obtained by getting it from the informers' cache- see the getter func passed as argument to HandleOwnedResourceNamespacedFunc.
At the time when a controller starts each informer needs to sync and it appears that at that time the Orders handler runs before the CertificateRequests have been cached and we consistently get these errors on startup for each Order present in the cluster:
E0816 11:52:45.832407       1 util.go:80] cert-manager/controller/certificaterequests/handleOwnedResource "msg"="error getting referenced owning resource" "error"="certificaterequest.cert-manager.io \"test-acme-certificate-2-fdddc\" not found" "related_resource_kind"="CertificateRequest" "related_resource_name"="test-acme-certificate-2-fdddc" "related_resource_namespace"="default" "resource_kind"="Order" "resource_name"="test-acme-certificate-2-fdddc-3482818700" "resource_namespace"="default" "resource_version"="v1"
E0816 11:52:45.832508       1 util.go:80] cert-manager/controller/certificaterequests/handleOwnedResource "msg"="error getting referenced owning resource" "error"="certificaterequest.cert-manager.io \"test-acme-certificate-1-f6qwf\" not found" "related_resource_kind"="CertificateRequest" "related_resource_name"="test-acme-certificate-1-f6qwf" "related_resource_namespace"="default" "resource_kind"="Order" "resource_name"="test-acme-certificate-1-f6qwf-3604531314" "resource_namespace"="default" "resource_version"="v1"

This seems confusing for users who are potentially debugging other issues as the errors reads as if cert-manager was not able to get the CertificateRequest from kube API server, see #4345 and various Slack chats here, here, here and other places.
Special notes for your reviewer:
Alternatively this could have been solved by not looking up the owner object in cache in the handler, just enqueing the key, but I guess we still want to check that the owner exists and not do extra work if it is i.e deleted.
I considered whether this risks not showing users some actually important errors, but I think that if the owner is actually permanently not found the owned resource would eventually be garbage collected anyway.
Improves logging for 'owner not found' errors for `CertificateRequest`s owning `Order`s.

/kind cleanup

e2e tests are failing because Venafi Cloud is broken I think

/test pull-cert-manager-e2e-v1-22

/test pull-cert-manager-e2e-v1-22


fix: cache initial data

It appears some time ago the initialData configuration was used as a fallback.  When #211 was merged, this behavior changed to be used with SSR like in the next.js example in the README.  Issue #230 explains this was the expectation. I'm using SSR, so im fine with the new behavior.
Since initialData is now not quickly revalidated, another issue (#308) has been raised.  Since initialData is not cached, and the mutate w/ callback grabs the curerent data from the cache, when initialData is used, undefined is returned.
fixes #308

@Timer @shuding @pacocoursey Anything else I need to do to get this reviewed?  I wasn't able to find any contributing docs, so I'm not sure how your process works.
Let me know if there's anything I can do to move this along.  Thanks!

@sergiodxa @pacocoursey Updated based on the feedback. ☺

When usSWR is used with SSR, a unique global instance is created to store the cache.
How could I prevent the initialData data from being stored in the server cache?

Ohh right, this will start filling the cache server side too.
You can use cache.clear() after or before the render to clear the cache. Maybe this change should also check if it’s running server side and don’t save in cache the initial data.

The current version of SWR will also fill the serve-side cache if not passed initialData.
What's the concern with using the cache server-side? memory consumption?
If we don’t want to use the cache server-side,  then what would the desired behavior be for useSWR server-side?
I don't have a good reason why, but I feel like adding a typeof window === 'undefined' in the library is not a great option.

I'm pretty sure right now SWR is never filling the cache server-side, because the fetch always happen client-side (effects only run client-side), even if you are using Suspense it will not because current (not experimental) version of React doesn't support Suspense for SSR so you need to avoid rendering the component doing the fetch at all.
The main concern with using the cache server-side is leaking data, imagine user A access /dashboard in Vercel, the data for that user will be stored in a cache, then user B access the same page, because the required data is already in cache we will SSR the dashboard using user A data instead of fetching user B data, then client-side we will revalidate the data and correctly fetch user B data updating the UI, while the happens the second user could access the first user dashboard and see its deployments, projects, etc.
This could be somehow avoided in a Serverless paradigm because each request should have its own Node.js instance with its own memory, nevertheless even in Serverless you usually want to keep a function warm if you are receiving multiple requests to avoid the cold start time, so you could still leak data between users.

@aj-may So when the fix will be released ?

@sergiodxa Ahh, your right!  I just tested it again and master doesn't fill the cache server side.  I push an update that will check the IS_SERVER value before caching.
@oran1248 I'm not a maintainer so I can't answer that question, but I just pushed an update to address comments.

@Timer @shuding @pacocoursey can I get a re-review on this?

TBH I don't think it's a good idea to directly write to cache, in the data read phrase. Let me try to explain my concerns.
Correctness
Usually cache read is always safe because it doesn't change the data. However mixing cache read with write will cause unexpect issues, for example it causes a side effect:
useSWR('data', { initialData: 1 }) // → 1
useSWR('data')                     // → 1

// changing the order will cause a different result
useSWR('data')                     // → undefined
useSWR('data', { initialData: 1 }) // → 1

If you have a complex component tree, with Suspense or Concurrent mode enabled in the future, it will be impossible to track these side effects.
The data flow of SWR is a loop, which makes things easier to maintain:
                 +--> read cache ----+
                 |                   |
  render         |                   v
+--------------->+                 fetch
  mutate         |                   |
                 |                   |
                 +--- write cache <--+

As you can see, cache read happens on render, which is the same as React itself: render is pure, and doesn't have any side effect. Then fetch and cache write are wrapped with useEffect, which can cause side effects.
Generally SWR obeys the rules of React, which ensures its correctness.
Performance
We plan to support different cache backend in the future. So it can be a Map (memory), localStorage (disk, sync), IndexedDB (disk, async) or even a remote storage (network). That means cache write can somehow be very expensive, comparing to read.
API Design
Regarding this issue (#230), this is one of my regrets in SWR's current API. initialData is per hook, and it's treated as a "fallback", rather than a "cache preset" (which is what this PR trying to do):
const { data } = useSWR('data', { initialData: 1 })

// the mental model is more like
const data = useSWR('data').data || 1

There're many issues with that API design. It's a wrong direction and we shouldn't have gone with it. Instead, the correct way of doing "presets" is context (SWRConfig). Imagine this API:
<SWRConfig value={{ initialData: { data: 1 } }}>
  <Component/>
</SWRConfig>

The context provides a default cache object, that all its children can read from or override to. The beauty is it doesn't add any extra logic to the SWR hook.
With the new cache interface (thanks @sergiodxa), I think we should even simplify it to:
<SWRConfig value={{ cache: initialCache }}>
  <Component/>
</SWRConfig>

So we can have namespaced cache and initial data at the same time, and it will be extremely friendly for SSR/SSG as well.

@shuding That makes sense to me. However, I'm not sure how it will fit into Next's SSG patterns. Since static generation is per-page, but the SWRConfig goes in the root of the app, how would statically-generated data get passed to SWRConfig?
I want to share a single page's static data across my Next site, similar to Gatsby's useStaticQuery.
Should I call cache.set('page-data', staticData) on the page's mount in order to share the static data globally, and forget initialData altogether?

I have the same issue,
I have fundraising page and which uses initial data and I have an other end point for adding donations. when I add a donation I want to update the running total on the fundraising page. I can't just revalidate the page because I have no guarantee that the page endpoint has updated in time I have to mutate it locally.
I can mutate the page by key when it doesn't exist in cache because I need to know the old page data before sending it modified page data. I'm forced to do something like this:
const FundraisingPage = ({ pageData }: Props) => {
  //  figure out unique page url for page cacheId
  const router = useRouter();
  const { slug } = router.query;
  const slugString = queryAsString(slug);
  const url = `${createFundraisingPageUrl({ slug: slugString })}`;

  // page cache
  const opts = { initialData: pageData };
  const { data, error, mutate } = useSwrGet(url?.length ? url : null, opts);
  // manually setting cache as this doesn't seem to happen with swr for ssr only on the browser
  useEffect(() => {
    if (data) {
      cache.set(url || "", data);
    }
  }, []);

.....

I have the same issue,
I have fundraising page and which uses initial data and I have an other end point for adding donations. when I add a donation I want to update the running total on the fundraising page. I can't just revalidate the page because I have no guarantee that the page endpoint has updated in time I have to mutate it locally.
I can mutate the page by key when it doesn't exist in cache because I need to know the old page data before sending it modified page data. I'm forced to do something like this:
const FundraisingPage = ({ pageData }: Props) => {
  //  figure out unique page url for page cacheId
  const router = useRouter();
  const { slug } = router.query;
  const slugString = queryAsString(slug);
  const url = `${createFundraisingPageUrl({ slug: slugString })}`;

  // page cache
  const opts = { initialData: pageData };
  const { data, error, mutate } = useSwrGet(url?.length ? url : null, opts);
  // manually setting cache as this doesn't seem to happen with swr for ssr only on the browser
  useEffect(() => {
    if (data) {
      cache.set(url || "", data);
    }
  }, []);

.....

I might be reading this incorrectly, but 2 thoughts:

If you're using query parameters in router.query, rather than dynamic routes, they won't exist on the server. This is why it's not working for SSR. You should be using get server side props from Next.js if you want the initial server load to always be up to date (I think, I've only used getStaticProps.) Also, use dynamic routes instead of query parameters.

Your server should return to you only after the money has posted to your database. I personally wouldn't optimistically render for something as sensitive as dollar amounts, but that's your call. In any case, revalidating should be safe by the time you've POSTed your data.

A pattern I like: POST data to the server, it returns the mutated data, and then inject that into SWR's cache.

I might be reading this incorrectly, but 2 thoughts:

If you're using query parameters in router.query, rather than dynamic routes, they won't exist on the server. This is why it's not working for SSR. You should be using get server side props from Next.js if you want the initial server load to always be up to date (I think, I've only used getStaticProps.) Also, use dynamic routes instead of query parameters.

Your server should return to you only after the money has posted to your database. I personally wouldn't optimistically render for something as sensitive as dollar amounts, but that's your call. In any case, revalidating should be safe by the time you've POSTed your data.

A pattern I like: POST data to the server, it returns the mutated data, and then inject that into SWR's cache.

@aj-may
I ended up checking if an identical URL and request body already has been sent, then settings revalidateOnMount to false.
Then it fetches only onces, and then only use the cache if it exists.
  const response = useSWR<Data, Error>(
    apiUrl && token ? [apiUrl, 'GET', reqData] : null,
    {
      // If we already have cached results, we don't want to call the endpoint again.
      // If we don't have cached results, then call the end point
      revalidateOnMount: !cache.keys().some((k) => apiUrl && k.includes(apiUrl) && reqData && k.includes(reqData)),
      revalidateOnFocus: false,
      revalidateOnReconnect: false,
      refreshWhenOffline: false,
      refreshWhenHidden: false,
    },
  );

Not sure if it fixes your request, but it worked for me.
Consider looking at swr-sync-storage if you want to persist the data on page refresh :)

#1017 is going to cover this very same use case in a more general way, which we are aiming to launch soon. 🎉

Closing this PR since #1017 was landed already. Docs: https://swr.vercel.app/advanced/cache.


feat: move icons and tokens lib into this repo

Moved in from odubya/covalent-sigma.

Description
Work was done previously in a different repo around the font file with Teradata create icons and also around the color defines in the design system. This moves that work into this main covalent repo.
Test Steps

[ ] npm ci
[ ] npm run style-dictionary

General Tests for Every PR

[x] npm run start still works.
[x] npm run lint passes.
[-] npm run stylelint passes.
[x] npm test passes and code coverage is not lower.
[x] npm run build still works.

Screenshots or link to StackBlitz/Plunker

same output as in covalent-sigma repo

:tada: This PR is included in version 4.5.0 :tada:
The release is available on:

v4.5.0
GitHub release

Your semantic-release bot :package::rocket:


External 6v power

I'm trying to use an external power source with 6V (10A, so plenty). I've managed to compile the binary myself and it works fine out of the box.
Now I'm trying to disable the voltage check by uncommenting this line and commenting the line above.
Compilation and flashing works as expected after that change, however I can still not use the blind with the external power source, but it continues to work with the battery.
Is there another place in the code that I need to edit?
Thank you very much again for this amazing project and your continued help!

After digging more it seems like the setting is read from EEPROM. I'm not sure what the best way is to disable this. I noticed that there is a setting READ_DEFAULT_SPEED_FROM_EEPROM, but I couldn't find anything similar for the other settings.
Should I modify the firmware to add similar variables for other settings or is there a better way?

@mjuhanne Created a PR here https://github.com/mjuhanne/fyrtur-motor-board/pull/15/files
Please take a look and thank you!