[BUG] Improve Kubernetes node drain support

Describe the bug
After rolling k8s nodes with StatefulSet workloads in AWS auto-scaling group — first creating new nodes, then cordoning and draining old nodes, then one by one terminating the EC2 instance. Some (out of many) volumes ended up "attached" to a non-existing node. This caused a StatefulSet pod to get stuck after being scheduled to a new node. The "Down" node couldn't be deleted from the pool either before manually detaching the volume.
To Reproduce
Not sure if this reproduces reliably, but I've seen this twice now.

Deploy a number of StatefulSets with PVCs on a k8s node group deployed as an AWS auto-scaling group
Update the ASG launch template
Roll the group with https://github.com/hellofresh/eks-rolling-update
Observe some pods unable to be scheduled due to failure in volume attachment

Expected behavior
Volumes should get detached automatically from nodes that are being drained, and especially the ones that don't exist at all.
Log
Failing pod event:
AttachVolume.Attach failed for volume "pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c" : rpc error: code = FailedPrecondition desc = The volume pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c cannot be attached to the node ip-10-0-197-215.eu-west-2.compute.internal since it is already attached to the node ip-10-0-110-63.eu-west-2.compute.internal

Longhorn volume event:
Error stopping pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c-r-13878a7f: Operation cannot be fulfilled on instancemanagers.longhorn.io "instance-manager-r-9672e5cb": the object has been modified; please apply your changes to the latest version and try again

Many errors like this in one of the longhorn-manager logs:
1129:2020-07-22T21:02:48.974414429Z E0722 21:02:48.974300       1 engine_controller.go:668] fail to update status for engine pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c-e-50a061ed: failed to list replicas from controller 'pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c': Failed to execute: /var/lib/longhorn/engine-binaries/longhornio-longhorn-engine-v1.0.0/longhorn [--url <IP_ADDRESS>:10001 ls], output , stderr, time="2020-07-22T21:02:48Z" level=fatal msg="Error running ls command: failed to list replicas for volume <IP_ADDRESS>:10001: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = \"transport: Error while dialing dial tcp <IP_ADDRESS>:10001: connect: no route to host\""

Environment:

Longhorn version: 1.0.0
Kubernetes version: EKS 1.17.6
Node OS type and version: EKS-optimised Amazon Linux 2

Additional context
This happened when workload nodes are hosting some volumes and when there's a separate group for Longhorn volumes.

@khushboo-rancher Can you help to reproduce the issue? Not sure if autoscaling group is needed. Probably give it a try without autoscaling group first.
@excieve Can you generate a support bundle and send it to<EMAIL_ADDRESS>Just in case if we cannot reproduce the issue.

Without the autoscaling group, I was not able to repro the issue. After draining of node, the pod moves to another node and volume successfully attached to the new node.
I'll try to repro this with autoscaling and update.

@yasker With the autoscaling group also, I couldn't reproduce the reported issue. I followed the below steps to reproduce the issue.
Steps:

Create a cluster (1 master, 3 workers) with EKS auto-scaling group enabled.
Deploy multiple numbers of StatefulSet with volume attached.
Update the ASG launch template with a new template.
Roll the group with https://github.com/hellofresh/eks-rolling-update

I observed the nodes going to cordon state first, then started to drain and getting terminated one by one. At this point in time pods got evicted from the node and moved to another. The respective volume got detached and attached to a new node smoothly.
Validated the data written in the volume also.
Logs :
longhorn-support-bundle_5ba7c270-5299-48e4-a53f-214e49a9c998_2020-07-24T01-01-55Z.zip
@excieve Let me know if there is any other step/configuration you might be having in your set up which I'm missing here.

@khushboo-rancher The setup we have looks like this:

EKS cluster 1.17
4 custom worker groups each with its own ASG + cluster-autoscaler operating on (ii) and (iii):

Workloads with EBS-backed storage
Workloads with no storage
Workloads with Longhorn-backed storage
Longhorn storage

The issue happens for us when rolling (iii) as described in the ticket. The workloads are created and managed by the Redis cluster operator. Perhaps it intervenes to heal the cluster, which causes some additional re-attachments.
I'll try to replicate this once more and generate a support bundle. Thanks for your time!

When trying to reproduce it I ended up with two stuck volumes, but this time in a different way:
MountVolume.SetUp failed for volume "pvc-0ead94bb-59b6-4a88-8f0f-e0e479a3cb37" : kubernetes.io/csi: mounter.SetupAt failed: rpc error: code = InvalidArgument desc = There is no block device frontend for volume pvc-0ead94bb-59b6-4a88-8f0f-e0e479a3cb37

The volume in question was in a "Detached" state, despite a rescheduled pod waiting for it. Attaching it manually to the pod's node using Longhorn UI resolved this.
Another volume had a similar issue, but deleting the pod made it being able to attach automatically on a recreated pod (this didn't help with the previous volume).
Then I rolled the same group again and had two issues with stuck volumes. One of them new — the volumes were hanging in the "attaching" state until manually detaching it (after which it was able to successfully re-attach). I haven't seen this happen before.
AttachVolume.Attach failed for volume "pvc-35b87577-6ca6-4bcd-81d2-8bb2d2b45881" : rpc error: code = Aborted desc = The volume pvc-35b87577-6ca6-4bcd-81d2-8bb2d2b45881 is attaching

And finally the actual issue from the description again. This time I observed more closely what was happening and noticed that these volumes (pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7 and pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c) were first unmounted when draining their workload nodes and then for some reason re-mounted on the same nodes despite them being cordoned and draining. I can't find this in the logs anymore probably because the corresponding managers are now terminated along with the nodes.
At the same time the corresponding VolumeAttachment resources have status with attached = false, e.g.:
apiVersion: storage.k8s.io/v1
kind: VolumeAttachment
metadata:
  annotations:
    csi.alpha.kubernetes.io/node-id: ip-10-0-235-9.eu-west-2.compute.internal
  creationTimestamp: "2020-07-24T15:17:14Z"
  finalizers:
  - external-attacher/driver-longhorn-io
  name: csi-ebe8a47464c6ad16bde499e3a48d64b01a45192956a9491d77d69e4922df49c9
  resourceVersion: "11486636"
  selfLink: /apis/storage.k8s.io/v1/volumeattachments/csi-ebe8a47464c6ad16bde499e3a48d64b01a45192956a9491d77d69e4922df49c9
  uid: b90daa53-d269-4d28-a647-ee25ad42816e
spec:
  attacher: driver.longhorn.io
  nodeName: ip-10-0-235-9.eu-west-2.compute.internal
  source:
    persistentVolumeName: pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7
status:
  attachError:
    message: 'rpc error: code = FailedPrecondition desc = The volume pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7
      cannot be attached to the node ip-10-0-235-9.eu-west-2.compute.internal since
      it is already attached to the node ip-10-0-123-229.eu-west-2.compute.internal'
    time: "2020-07-24T17:20:46Z"
  attached: false

But this same volume is displaying as "Attached" in Longhorn UI:

A wild guess: I wonder if this could be happening due to PodDisruptionBudgets for these StatefulSets not letting the pod to be rescheduled for some time, but Longhorn treating this draining as a call to detach unconditionally, then remounts when the pod doesn't migrate and finally get stuck despite the node being finally gone.
I'll send the support bundle too, it's taken at the point of two mentioned volumes being in this state.

Right, I've experimented some more and it indeed looks like the original issue is related to PDBs. My StatefulSets have 2 pods each and PDBs for them allow a maximum of 1 pod to be disrupted at a time. This means that when draining, k8s will keep some pods and their nodes alive until one of two pods in each set is successfully running on new nodes to prevent service outage. With this workload it usually takes a couple of minutes for a pod to get the volume reattached, init and pass the readiness probe.
It seems like Longhorn might not like this sometimes and have a strange state on nodes that PDBs keep alive for some time. I wonder if this happens because the instance manager pods get evicted while workload pods with volumes are not. Should they have a toleration for draining?
When I modify the PDBs such that they allow both pods in a set to be disrupted, I no longer see this issue (tried rolling two times).
At the same time I'm still seeing the infinitely "attaching" volumes sometimes, which seem to be caused by this:
time="2020-07-24T21:01:10Z" level=warning msg="Dropping Longhorn engine longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa out of the queue: fail to sync engine for longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa: invalid Instance Manager instance-manager-e-28f49254, state: unknown, IP: <IP_ADDRESS>"

time="2020-07-24T21:01:10Z" level=warning msg="Error syncing Longhorn engine longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa: fail to sync engine for longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa: invalid Instance Manager instance-manager-e-28f49254, state: unknown, IP: <IP_ADDRESS>"

time="2020-07-24T21:01:10Z" level=warning msg="Error syncing Longhorn engine longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa: fail to sync engine for longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa: invalid Instance Manager instance-manager-e-28f49254, state: unknown, IP: <IP_ADDRESS>"

E0724 21:01:10.786772       1 engine_controller.go:210] fail to sync engine for longhorn-system/pvc-0b00746d-0a91-4d75-b548-cc6e8d7037b9-e-6f65f2fa: invalid Instance Manager instance-manager-e-28f49254, state: unknown, IP: <IP_ADDRESS>

Which also seems to be related to an instance manager that doesn't exist anymore (but an InstanceManager CRD still exists — they don't seem to be removed when nodes are terminated).

Here may be the root cause. Since some logs are missed in the support bundle, I cannot guarantee the analysis is accurate:

During the node draining, the related engine manager pod is evicted hence the volume on the node gets crashed unexpectedly. Then Longhorn will automatically detach and reattach the volume as the auto-recovery mechanism. (Cannot find any log here.)
During the auto detachment, the workload becomes terminating and Kubernetes will send the detach request to Longhorn CSI plugin.
The CSI plugin finds the volume is already detaching/detached hence it will blindly report success. But actually this detachment is not controlled/issued by Kubernetes. And there will be an auto reattachment operation after the detachment. The detachment is a transient state for the volume.

2020-07-24T15:16:05.012899952Z time="2020-07-24T15:16:05Z" level=info msg="GRPC request: {\"node_id\":\"ip-10-0-123-229.eu-west-2.compute.internal\",\"volume_id\":\"pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7\"}"
2020-07-24T15:16:05.012960414Z time="2020-07-24T15:16:05Z" level=info msg="ControllerServer ControllerUnpublishVolume req: volume_id:\"pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7\" node_id:\"ip-10-0-123-229.eu-west-2.compute.internal\" "
2020-07-24T15:16:05.015096193Z time="2020-07-24T15:16:05Z" level=error msg="GRPC error: rpc error: code = Aborted desc = The volume pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7 is detaching"

2020-07-24T15:17:08.079802047Z time="2020-07-24T15:17:08Z" level=info msg="GRPC call: /csi.v1.Controller/ControllerUnpublishVolume"
2020-07-24T15:17:08.080826605Z time="2020-07-24T15:17:08Z" level=info msg="GRPC request: {\"node_id\":\"ip-10-0-123-229.eu-west-2.compute.internal\",\"volume_id\":\"pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7\"}"
2020-07-24T15:17:08.082716697Z time="2020-07-24T15:17:08Z" level=info msg="ControllerServer ControllerUnpublishVolume req: volume_id:\"pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7\" node_id:\"ip-10-0-123-229.eu-west-2.compute.internal\" "
2020-07-24T15:17:08.084673822Z time="2020-07-24T15:17:08Z" level=info msg="don't need to detach Volume pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7 since we are already detached from node ip-10-0-123-229.eu-west-2.compute.internal"

Kubernetes is informed that the volume is detached then it will launch a new workload with the volume. But the volume has been automatically reattached to the draining node (before the node is gone). ((Cannot find any logs for this reattachment) Then the workload sticks there.

2020-07-24T15:17:14.212174175Z time="2020-07-24T15:17:14Z" level=info msg="ControllerServer ControllerPublishVolume req: volume_id:\"pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7\" node_id:\"ip-10-0-235-9.eu-west-2.compute.internal\" volume_capability:<mount:<fs_type:\"ext4\" > access_mode:<mode:SINGLE_NODE_WRITER > > volume_context:<key:\"baseImage\" value:\"\" > volume_context:<key:\"fromBackup\" value:\"\" > volume_context:<key:\"numberOfReplicas\" value:\"3\" > volume_context:<key:\"staleReplicaTimeout\" value:\"30\" > volume_context:<key:\"storage.kubernetes.io/csiProvisionerIdentity\" value:\"1595117863611-8081-driver.longhorn.io\" > "
2020-07-24T15:17:14.216267097Z time="2020-07-24T15:17:14Z" level=error msg="GRPC error: rpc error: code = Aborted desc = The volume pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c is attaching"

......

2020-07-24T15:17:29.983502391Z time="2020-07-24T15:17:29Z" level=info msg="ControllerServer ControllerPublishVolume req: volume_id:\"pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7\" node_id:\"ip-10-0-235-9.eu-west-2.compute.internal\" volume_capability:<mount:<fs_type:\"ext4\" > access_mode:<mode:SINGLE_NODE_WRITER > > volume_context:<key:\"baseImage\" value:\"\" > volume_context:<key:\"fromBackup\" value:\"\" > volume_context:<key:\"numberOfReplicas\" value:\"3\" > volume_context:<key:\"staleReplicaTimeout\" value:\"30\" > volume_context:<key:\"storage.kubernetes.io/csiProvisionerIdentity\" value:\"1595117863611-8081-driver.longhorn.io\" > "
2020-07-24T15:17:29.987886364Z time="2020-07-24T15:17:29Z" level=error msg="GRPC error: rpc error: code = FailedPrecondition desc = The volume pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7 cannot be attached to the node ip-10-0-235-9.eu-west-2.compute.internal since it is already attached to the node ip-10-0-123-229.eu-west-2.compute.internal"

The node is gone then the volume and the related engine manager pod is considered as Unknown.

- typemeta:
    kind: ""
    apiversion: ""
  objectmeta:
    name: instance-manager-e-4aef6e75
    generatename: ""
    namespace: longhorn-system
    selflink: /apis/longhorn.io/v1beta1/namespaces/longhorn-system/instancemanagers/instance-manager-e-4aef6e75
    uid: b66e5a91-c2d6-499f-808f-57447d910973
    resourceversion: "11444629"
    generation: 1
    creationtimestamp: "2020-07-24T13:05:53Z"
    deletiontimestamp: null
    deletiongraceperiodseconds: null
    labels:
      longhorn.io/component: instance-manager
      longhorn.io/instance-manager-image: longhornio-longhorn-instance-manager-v1_20200514
      longhorn.io/instance-manager-type: engine
      longhorn.io/node: ip-10-0-123-229.eu-west-2.compute.internal
    annotations: {}
    ownerreferences:
    - apiversion: longhorn.io/v1beta1
      kind: Node
      name: ip-10-0-123-229.eu-west-2.compute.internal
      uid: fa0df2e5-c451-4d1d-bdaf-877a8f47ba0f
      controller: null
      blockownerdeletion: true
    initializers: null
    finalizers:
    - longhorn.io
    clustername: ""
    managedfields: []
  spec:
    image: longhornio/longhorn-instance-manager:v1_20200514
    nodeid: ip-10-0-123-229.eu-west-2.compute.internal
    type: engine
    engineimage: ""
  status:
    ownerid: ip-10-0-218-139.eu-west-2.compute.internal
    currentstate: unknown
    instances:
      pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7-e-bfe75919:
        spec:
          name: pvc-3d6fe7af-7536-4367-8a33-249d8c2550d7-e-bfe75919
        status:
          endpoint: ""
          errormsg: ""
          listen: ""
          portend: 10009
          portstart: 10009
          state: running
          type: ""
          resourceversion: 0
      pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c-e-50a061ed:
        spec:
          name: pvc-d937c093-5ba2-4ee7-9abe-563cb94d215c-e-50a061ed
        status:
          endpoint: ""
          errormsg: ""
          listen: ""
          portend: 10008
          portstart: 10008
          state: running
          type: ""
          resourceversion: 0
    ip: <IP_ADDRESS>
    apiminversion: 1
    apiversion: 1

The simplest workaround is manually detaching the volume.
@yasker To solve this issue, we may need to distinguish auto detach&reattach from regular detach and attach.
BTW, according to the above analysis, this issue is caused by the race condition. I am not sure why it is not triggered without setting PDBs.

@shuo-wu Nice find! Can we detach the volume regardless of if the volume is detaching or not? We can check if it's detaching or not later, but I am not sure if it's really needed if the detach becomes idempotent.

detach the volume regardless of if the volume is detaching or not?

Do you mean returning nil for the detach request if the volume is already detaching? I don't think that is the key point. Maybe we can cancel the following reattachment in this case if Longhorn receives detach requests from users/Kubernetes.

As another datapoint: by now this happens every time we rolling-upgrade nodes no matter how many volumes and volume-consuming pods there are. It gets pretty difficult to manage once there are hundreds as each stuck volume needs to be identified, then manually detached and then it takes some minutes until it finally attaches and mounts, slowing everything down.

I am getting all the same type errors after kured ran across my nodes today...
longhorn-support-bundle_8e0655a7-95cd-4269-840f-89a99f866561_2020-09-03T17-41-55Z.zip

We get the same problem occasionally when we drain our nodes. As a workaround, we deploy a helper program on every node by DaemonSet. The helper program blocks deletion of Longhorn Instance Manager pods until all pods which mount Longhorn volumes finish to detach during kubectl drain. It works fine for our situation, so we would like to share something we've learned.
Environment

Kubernetes v1.18.6
Longhorn v1.0.2 with fix for node.session.scan (custom build)
Ubuntu 18.04
Set node.session.scan = manual in iscsid.conf
Our clusters are recreated everyday for testing purposes in dev environment.

Recreate clusters by creating and deleting nodes one by one.
Every node is drained by kubectl drain before deletion.

Problem
We had the following problems when we recreated clusters by draining nodes:

The volume remains stuck occasionally bound after draining (same as this issue)

Instance Manager (Engine and Replica) pods are not managed by DaemonSet, so when a node is drained, both Instance Manager pods and application pods which mount Longhorn volumes are deleted simultaneously. Therefore application pods cannot detach properly during kubectl drain.
DaemonSet managed pods are not deleted by kubectl drain. We use --ignore-daemonsets option to ignore them.

All replicas of volumes are lost if draining nodes happens too fast.

We need to check if the new replicas sync is done.
https://github.com/longhorn/longhorn/issues/298 may fix it.

Frequent deleting of replicas generates many old snapshots.

Create a recurring backup job solved this problem.
https://github.com/longhorn/longhorn/issues/685 may fix it.

Workaround
As a workaround, we deploy the following helper program on every node by DaemonSet (We call it longhorn-evictor). With this helper, we do not see the problems above.
Source code: https://gist.github.com/tksm/667c0562009df7c57a8cc1126d68fc52#file-main-go (not for production use)
Basically it works as follows on every node.

Create PodDisruptionBudeget for Longhorn Instance Manager on the node to block deletion during kubectl drain.
Wait for the node to become Unschedulable.

Consider it as kubectl drain start.

Wait for all longhorn volumes on the node to be detached.

Ensure there are no longhorn volumes whose currentNodeID or ownerID is assigned this node.

Evict Longhorn replicas on the node by deleting replicas.longhorn.io objects.
Delete PodDisruptionBudeget for Longhorn Instance Manager on the node.

Longhorn Instance Manager pods will be safely deleted.

PodDisruptionBudeget for Longhorn Instance Manager (Engine) looks like this. maxUnavailable: 0 blocks deletion of pods.
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  labels:
    stateful.zlab.co.jp/app: longhorn-evictor
  name: longhorn-engine-demo-tkusumi118-worker-default-9d5e2007-9k8hb
  namespace: longhorn-system
spec:
  maxUnavailable: 0
  selector:
    matchLabels:
      longhorn.io/component: instance-manager
      longhorn.io/instance-manager-type: engine
      longhorn.io/node: demo-tkusumi118-worker-default-9d5e2007-9k8hb

@yasker Just wanted to mention that we tried out this PDB when draining nodes and it worked flawlessly! Every workloads that uses volumes migrated in a matter of seconds with nothing getting stuck, improving general service stability a lot during maintenance. Thanks for this @tksm!

** reproduce steps:**

Create a cluster of 3 nodes. Install Longhorn.
Create a volume with 2 replicas. Create PVC,PV from the volume
Create a statefulset of size 1 which uses the PVC.
Wait until the workload pod becomes running. Find the node on which the workload pod is located. Let's say it is node-1
cordon, then force drain node-1. Assume that the k8s scheduler chooses node-2 for the workload pod

Observe that there are 2 scenarios:

The volume detaches from node-1, reattach to node-1 (because of the auto attachment), detaches from node-1, and finally attaches to node-2. The whole process takes about 2-3 minutes. Running kubectl get volumes -n longhorn-system -w, we will see:

testvol1   attached    healthy      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-1   22h
testvol1   detaching   unknown      True<PHONE_NUMBER>                                    22h
testvol1   detaching   unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-1   22h
testvol1   attaching   unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-1   22h
testvol1   attached    unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-1   22h
testvol1   attached    unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-1   22h
testvol1   detaching   unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   attaching   unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-2   22h
testvol1   attached    unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-2   22h
testvol1   attached    healthy      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-2   22h

The volume detaches from node-1, reattach to node-1 (because of the auto attachment), and never detaches from node-1.

Most of the time, scenario#1 will happen. Sometimes scenario#2 happens. This is because of a race problem between CSI plugin calls and VolumeController's auto attachment feature as explained by @shuo-wu at https://github.com/longhorn/longhorn/issues/1631#issuecomment-664768769

test steps:

Create a cluster of 3 nodes. Install Longhorn.
Create a volume with 2 replicas. Create PVC,PV from the volume
Create a statefulset of size 1 which uses the PVC.
Wait until the workload pod becomes running. Find the node on which the workload pod is located. Let's say it is node-1
cordon, then force drain node-1. Assume that the k8s scheduler chooses node-2 for the workload pod

Observe that there is always 1 scenario: The volume detaches from node-1, attaches to node-2. The workload pod is able to start. The whole process takes ~ 15s.
Running kubectl get volumes -n longhorn-system -w, we will see:
testvol1   attached   healthy      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-1   22h
testvol1   detaching   unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   detached    unknown      True<PHONE_NUMBER>                                    22h
testvol1   attaching   unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-2   22h
testvol1   attached    unknown      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-2   22h
testvol1   attached    healthy      True<PHONE_NUMBER>   phan-cluster-v24-node-group2-2   22h

There's also a need to protect replica instances, so they don't end up all getting killed during rolling cluster upgrade. Even if you have multiple replicas, you can end up with failed volumes if rolling upgrade is fast enough and takes them all out one-by-one.
But that should probably be a separate issue/pr.

@tvanderka
We have a separate feature to deal with replica eviction.
In v1.1.0, users can use the following step to drain/shutdown nodes during maintaining:
(Let's say that we want to do maintaining on node-x)

Evict all replicas from the node-x (by feature https://github.com/longhorn/longhorn/issues/298)
Drain the node: kubectl drain. It doesn't have to be force drain. (by this feature and https://github.com/longhorn/longhorn/issues/1286)
Do maintaining work
terminate the node and bring up a new one or uncordon the current node

Please let me know if this process work for you.

@PhanLe1010 I understand #298 is for manual eviction, that will not help in OKD/Openshift and other solutions with automated rolling upgrades. Openshift cluster upgrade is completely automated, and drains/upgrades/reboots nodes one at a time (or specified % of nodes).
Protecting replicas with PDB would be nice, you should be unable to "drain --force" the node if there's no other ready/synced replica somewhere else.

you should be unable to "drain --force" the node if there's no other ready/synced replica somewhere else.

I agree with this idea.
cc @yasker
Waiting for all replicas in the draining node to move to other nodes might take a long time and might cause the kubectl drain command to timeout. Therefore, we don't want to block users from draining the node if there are other healthy replicas on other nodes. This allows automation tools to drain the node quickly while ensuring that Longhorn volumes are safe.
However, if the draining node contains the only healthy replica, blocking is a must. In this case, users must take a manual intervention to evict the replicas from the draining node. I was thinking that Longhorn can trigger an auto eviction in this case but I can't think of a way to know on which condition Longhorn should do auto eviction. All Longhorn knows is that the node is unschedulable, which could mean the user is draining the node to prepare for upgrading or simply means that the user temporarily condors the node.

If we want to fully automate the process, we need to agree on one convention: unschedulable node is the node that is being drained. Every replica must move out of the unschedulable node

I don't think there is an easy solution for the automatic rolling upgrade case. The biggest reason is moving a replica from one node to another is a long process. It can take hours or even days. That's why I don't think automatic eviction is the answer here. And it's possible that no eviction is required since volume might recover to full healthy by finish rebuilding on existing replicas.
In that sense, it's likely we need to block the drain operation if the only healthy replica of any attached volume is on that node.
However, there is one case that we might don't want to block the drain for the last healthy replica: for an application can do replication by itself and only need a single replica from Longhorn. Normally it's OK to lose the replica (and the workload pod) in that case since the replication is done at the application level. In that case, we need to add a global setting to allow draining the node with the last healthy replicas. By default, the drain will be blocked for the last healthy replicas.
Still, I don't have a good answer to what should we do about that last healthy replica. I feel we need some mechanism established between Longhorn and the system performing the automatic rolling upgrade, to make sure it's not going to drain all the healthy replicas of one volume at the same time. Something similar to the PodDisruptionBudget that can communicate and affect the system's decision on which nodes to drain.

Thanks @yasker
The argument about auto eviction of volume with the last healthy replica makes sense. We should have a setting for that.
@tvanderka We will add the feature to this issue since it is a pretty quick modification.

Simply blocking drain on last replica should be sufficient. Other scenarios mentioned would require manual intervention, you could evict the replica manually or detach the volume.
When I drain a node, new replacement replica is created. If it does not sync before last remainng replica gets drained/evicted, the volume goes down. It gets "salvaged" later and seems fine in longhorn, except pods using it keep returning i/o errors.
I worked around this by creating a PDB blocking eviction of any instance-manager-r pods and manually updating it to allow 1 go down only after resync was complete and 2 replicas were ready. Works but ...
I think rolling cluster upgrade requires "partial sync" functionality to work reasonably well, to not throw away all existing data when node/replica comes up again. Assuming rolling upgrade does not actually "replace" the whole node and wipe your data with it (which is a case with cluster autoscaler I guess).

@PhanLe1010 auto-eviction would not help, could even make things worse as the upgrade would just kill things in the middle of eviction process.

@tvanderka Thanks for the suggestion.
Yeah. I agree. We will not do auto eviction.
As @yasker mentioned, we will have a global setting for user to choose whether Longhorn should block kubectl drain if the is replica on the draining node which is the last replica of a volume.
How do you think?

Verified on longhorn-master - 10/20/2020
Validation - Pass
Reproduced scenario 1 from https://github.com/longhorn/longhorn/issues/1631#issuecomment-708840175 multiple times. However, I couldn't reproduce scenario 2. With the fix, the volume detaches and attaches to another node.
kubectl get volumes -n longhorn-system -w
NAME            STATE      ROBUSTNESS   SCHEDULED   SIZE         NODE            AGE
volume-test   attached   healthy      True<PHONE_NUMBER>   <node-1>   10m
volume-test   attached   healthy      True<PHONE_NUMBER>   <node-1>   11m
volume-test   detaching   unknown      True<PHONE_NUMBER>                   11m
volume-test   detached    unknown      True<PHONE_NUMBER>                   11m
volume-test   detached    unknown      True<PHONE_NUMBER>                   11m
volume-test   attaching   unknown      True<PHONE_NUMBER>   <node-2>   11m

Drain with 'Allow Node Drain with the Last Healthy Replica' disabled and more than one replica.
Volume move to another node successfully, the instance managers get evicted at the end.

node/<node-1> cordoned
evicting pod "wk-1-689bdd644-pqq2d"
evicting pod "instance-manager-e-44cfa350"
evicting pod "instance-manager-r-689ac220"
error when evicting pod "instance-manager-r-689ac220" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pod "instance-manager-e-44cfa350" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
pod/wk-1-689bdd644-pqq2d evicted
evicting pod "instance-manager-r-689ac220"
evicting pod "instance-manager-e-44cfa350"
error when evicting pod "instance-manager-r-689ac220" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pod "instance-manager-e-44cfa350" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod "instance-manager-r-689ac220"
evicting pod "instance-manager-e-44cfa350"
error when evicting pod "instance-manager-r-689ac220" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pod "instance-manager-e-44cfa350" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod "instance-manager-r-689ac220"
evicting pod "instance-manager-e-44cfa350"
pod/instance-manager-e-44cfa350 evicted
pod/instance-manager-r-689ac220 evicted
node/<node-1> evicted

Drain with 'Allow Node Drain with the Last Healthy Replica' disabled and one replica.
Volume move to another node successfully, the replica doesn't move.

node/khush-test-lh-wk1 cordoned
evicting pod "csi-snapshotter-54b5b6487b-6fj78"
evicting pod "csi-attacher-7466697f7b-c6fhh"
evicting pod "csi-provisioner-5d6ff768f7-jz4s9"
evicting pod "longhorn-driver-deployer-695b98db65-f7q4c"
evicting pod "csi-resizer-64c4db9977-7nc62"
evicting pod "coredns-849545576b-x7s4r"
evicting pod "instance-manager-e-44cfa350"
evicting pod "csi-attacher-7466697f7b-gsxm2"
evicting pod "csi-snapshotter-54b5b6487b-hs54f"
evicting pod "csi-provisioner-5d6ff768f7-sj5wd"
evicting pod "wk-1-694486fcb4-ts8ck"
evicting pod "instance-manager-r-689ac220"
evicting pod "default-http-backend-598b7d7dbd-26ns7"
error when evicting pod "instance-manager-e-44cfa350" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pod "instance-manager-r-689ac220" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
pod/csi-provisioner-5d6ff768f7-sj5wd evicted
pod/csi-attacher-7466697f7b-gsxm2 evicted
pod/csi-snapshotter-54b5b6487b-6fj78 evicted
pod/longhorn-driver-deployer-695b98db65-f7q4c evicted
evicting pod "instance-manager-e-44cfa350"
evicting pod "instance-manager-r-689ac220"
error when evicting pod "instance-manager-e-44cfa350" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
error when evicting pod "instance-manager-r-689ac220" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
pod/csi-snapshotter-54b5b6487b-hs54f evicted
pod/default-http-backend-598b7d7dbd-26ns7 evicted
pod/wk-1-694486fcb4-ts8ck evicted
pod/csi-attacher-7466697f7b-c6fhh evicted
pod/csi-resizer-64c4db9977-7nc62 evicted
pod/csi-provisioner-5d6ff768f7-jz4s9 evicted
pod/coredns-849545576b-x7s4r evicted
evicting pod "instance-manager-e-44cfa350"
evicting pod "instance-manager-r-689ac220"
error when evicting pod "instance-manager-e-44cfa350" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod "instance-manager-e-44cfa350"
evicting pod "instance-manager-r-689ac220"
error when evicting pod "instance-manager-r-689ac220" (will retry after 5s): Cannot evict pod as it would violate the pod's disruption budget.
evicting pod "instance-manager-r-689ac220"
There are pending pods in node "<node-1>" when an error occurred: error when evicting pod "instance-manager-r-689ac220": global timeout reached: 2m0s
pod/default-http-backend-598b7d7dbd-rm29b
pod/instance-manager-e-44cfa350
pod/instance-manager-r-689ac220
error: unable to drain node "<node-1>", aborting command...

There are pending nodes to be drained:
<node-1>
error: error when evicting pod "instance-manager-r-689ac220": global timeout reached: 2m0s

Drain with 'Allow Node Drain with the Last Healthy Replica' enabled and one replica.
Volume move to another node successfully, the replica becomes faulted.

There is one drain failure observed when a cluster has 1 node which is configured as etcd, control plane and worker and is drained.
There are pending pods in node "<node-1>" when an error occurred: [error when evicting pod "csi-provisioner-5d6ff768f7-s265v": an error on the server ("<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body>\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.19.2</center>\r\n</body>\r\n</html>") has prevented the request from succeeding (post pods.policy csi-provisioner-5d6ff768f7-s265v), error when evicting pod "csi-snapshotter-54b5b6487b-9lnv4": an error on the server ("<html>\r\n<head><title>502 Bad Gateway</title></head>\r\n<body>\r\n<center><h1>502 Bad Gateway</h1></center>\r\n<hr><center>nginx/1.19.2</center>\r\n</body>\r\n</html>") has prevented the request from succeeding (post pods.policy csi-snapshotter-54b5b6487b-9lnv4)]

We get the same problem occasionally when we drain our nodes. As a workaround, we deploy a helper program on every node by DaemonSet. The helper program blocks deletion of Longhorn Instance Manager pods until all pods which mount Longhorn volumes finish to detach during kubectl drain. It works fine for our situation, so we would like to share something we've learned.
Environment

Kubernetes v1.18.6

Longhorn v1.0.2 with fix for node.session.scan (custom build)

Ubuntu 18.04

Set node.session.scan = manual in iscsid.conf

Our clusters are recreated everyday for testing purposes in dev environment.

Recreate clusters by creating and deleting nodes one by one.
Every node is drained by kubectl drain before deletion.

Problem
We had the following problems when we recreated clusters by draining nodes:

The volume remains stuck occasionally bound after draining (same as this issue)

Instance Manager (Engine and Replica) pods are not managed by DaemonSet, so when a node is drained, both Instance Manager pods and application pods which mount Longhorn volumes are deleted simultaneously. Therefore application pods cannot detach properly during kubectl drain.
DaemonSet managed pods are not deleted by kubectl drain. We use --ignore-daemonsets option to ignore them.

All replicas of volumes are lost if draining nodes happens too fast.

We need to check if the new replicas sync is done.
Manager: Add replica eviction support for node and disk #298 may fix it.

Frequent deleting of replicas generates many old snapshots.

Create a recurring backup job solved this problem.
[FEATURE] Clean up old Data after node failure #685 may fix it.

Workaround
As a workaround, we deploy the following helper program on every node by DaemonSet (We call it longhorn-evictor). With this helper, we do not see the problems above.
Source code: https://gist.github.com/tksm/667c0562009df7c57a8cc1126d68fc52#file-main-go (not for production use)
Basically it works as follows on every node.

Create PodDisruptionBudeget for Longhorn Instance Manager on the node to block deletion during kubectl drain.

Wait for the node to become Unschedulable.

Consider it as kubectl drain start.

Wait for all longhorn volumes on the node to be detached.

Ensure there are no longhorn volumes whose currentNodeID or ownerID is assigned this node.

Evict Longhorn replicas on the node by deleting replicas.longhorn.io objects.

Delete PodDisruptionBudeget for Longhorn Instance Manager on the node.

Longhorn Instance Manager pods will be safely deleted.

PodDisruptionBudeget for Longhorn Instance Manager (Engine) looks like this. maxUnavailable: 0 blocks deletion of pods.
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  labels:
    stateful.zlab.co.jp/app: longhorn-evictor
  name: longhorn-engine-demo-tkusumi118-worker-default-9d5e2007-9k8hb
  namespace: longhorn-system
spec:
  maxUnavailable: 0
  selector:
    matchLabels:
      longhorn.io/component: instance-manager
      longhorn.io/instance-manager-type: engine
      longhorn.io/node: demo-tkusumi118-worker-default-9d5e2007-9k8hb

@tksm  Can we achieve same as your gist with following steps? I know it might be overkill but I have to patch shutdown script of existing production server.
kubectl drain --ignore-daemonsets  --force --delete-emptydir-data  --pod-selector=longhorn-manager!=Replica --pod-selector=longhorn-manager!=Volume --pod-selector=longhorn.io/component!=instance-manager
kubectl drain --ignore-daemonsets  --force --delete-emptydir-data  --pod-selector=longhorn-manager!=Volume --pod-selector=longhorn.io/component!=instance-manager
kubectl drain --ignore-daemonsets  --force --delete-emptydir-data  --pod-selector=longhorn.io/component!=instance-manager
kubectl drain --ignore-daemonsets  --force --delete-emptydir-data

@imranrazakhan  Longhorn already supports the kubectl drain protection by PDB since v1.1.0. It was done in https://github.com/longhorn/longhorn-manager/pull/707 .
If we drain a node in Longhorn below v1.1.0, I think that we should wait for all volumes detached before draining instance-manager pods since the volume detachment will be done asynchronously. Please refer to canDeleteInstanceManagerPDB() method for details.

@tksm  Thanks for details.
For others who are using pre 1.1.0 following script will help
kubectl drain --ignore-daemonsets --delete-emptydir-data --pod-selector=longhorn.io/component!=instance-manager
for vol in `kubectl -n longhorn-system get Volume -o json |  jq '.items[] | .metadata.name' | sed 's/"//g'` ; do

  while [[ $(kubectl  -n longhorn-system get Volume $vol -o 'jsonpath={.status.state}') != "detached" ]];
  do
	echo "waiting volumw to detach." && sleep 1;
  done

done


Allow $column->setRenderer for Status column

Allow setRenderer for values NOT included in options list, currently the value is just spited into the template, it would be great to have an option to style those values in some way in addition to the status buttons.

It is already there:
$columnStatus::setRendererOnCondition()

Oh, i see, my fault, sorry.

The thing is, templates have greater priority that user renderers. I am sorry, i will remove the milestone for now before i will figure out whether i want to implement that or not. (it is probably easier to achieve by ColumnText with custom tempalte)

@juniwalk Ha!
I released new version with this functionality: http://ublaboo.paveljanda.com/datagrid/column#column-callback.
Now, you can easily (more or less..) modify ColumnStatusRenderer though it has template set:
$grid->addColumnCallback('status', function($column, $item) {
	if ($item->id == 2) {
		$column->setTemplate(NULL);
		$column->setRenderer(function() {
			return 'a';
		});
	}
});

Thanks, this is sufficient.


docs: hexo-util@1 & hexo-renderer-marked@2

Check List
Please read and check followings before submitting a PR.

[x] Others (Update, fix, translation, etc...)

https://github.com/hexojs/hexo-util/releases/tag/1.0.0
https://github.com/hexojs/hexo-renderer-marked/releases/tag/2.0.0

Please squash and merge. :wink:

LGTM.


[Visual Studio 2022] error C2011: 'sockaddr': 'struct' type redefinition

Required information
Operating system:
Windows 11 x64
Compiler version:
Visual Studio 2022
Eclipse iceoryx version:
v2.0.3
Observed result or behaviour:
I am developing a cross platform application and would like to integrate iceoryx into my app. I have no problem in linux but I get many errors such as the following when I am compiling the same source codes using Visual Studio 2022:
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\ws2def.h(240): error C2011: 'sockaddr': 'struct' type redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winsock.h(482): note: see declaration of 'sockaddr'
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\ws2def.h(442): error C2143: syntax error: missing '}' before 'constant'
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\ws2def.h(442): error C2059: syntax error: 'constant'
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\ws2def.h(496): error C2143: syntax error: missing ';' before '}'
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\ws2def.h(638): error C2011: 'sockaddr_in': 'struct' type redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winsock.h(309): note: see declaration of 'sockaddr_in'
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winsock2.h(136): error C2011: 'fd_set': 'struct' type redefinition
C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\um\winsock.h(65): note: see declaration of 'fd_set'

I compiled using /P and noticed winsock.h is included in my app. Is there any way to get around this issue in Windows?

That's weird. We only define sockaddr_un on Windows. Are you able to switch to winsock2.h? If not, maybe you can try some of the solutions proposed in https://stackoverflow.com/a/8294669


Fix for #272

Fixes #272. This change doesn't affect binary compatibility, so once it's merged I'll backport it to the 0.4 series and publish an 0.4.1.
I've added a test to verify that this doesn't get broken again (and confirmed that it fails without the change).
Note that derivation for encoders wasn't failing in this case (just decoders), but I've made the change across both for consistency's sake.

Current coverage is 81.32%

Merging #273 into master will decrease coverage by -0.11% as of 9f08c40

Powered by Codecov. Updated on successful CI builds.


Update to UMD / Isomorphic style

@spacejack Thank you for the invite!
The style we want to match is described in the TypeScript docs. Also some details in this comment.
This means we'll be splitting type declarations into multiple files, and organize them into a folder structure that matches Mithril's importable module paths. The ultimate goal is to have this on https://github.com/DefinitelyTyped/DefinitelyTyped.
I have found lodash to be an interesting example of this approach. They have all declarations in the index.d.ts, and they have minimal content in subfolders. Example:
index.d.ts
export = _;
export as namespace _;
declare var _: _.LoDashStatic;

declare namespace _ {
    interface LoDashStatic {
        toSafeInteger(value: any): number;
    }
    interface Dictionary<T> {
        [index: string]: T;
    }
}

toSafeInteger/index.d.ts
import { toSafeInteger } from "../index";
export = toSafeInteger;

Example use 1 (script)
var dict: _.Dictionary<string>
_.toSafeInteger(3.2);

Example use 2 (target ES5)
import jQuery from 'jquery-ts'

var dict: _.Dictionary<string>
_.toSafeInteger(3.2); // [ts] '_' refers to a UMD global, but the current file is a module. Consider adding an import instead.

Example use 3 (target ES5)
import jQuery from 'jquery-ts'
import * as _ from 'lodash'

var dict: _.Dictionary<string>
_.toSafeInteger(3.2); // Fixed

Example use 4 (target ES6)
import toSafeInteger = require('lodash/toSafeInteger') // [ts] Import assignment cannot be used when targeting ECMAScript 2015 modules. Consider using 'import * as ns from "mod"', 'import {a} from "mod"', 'import d from "mod"', or another module format instead.
import * as toSafeInteger from 'lodash/toSafeInteger' // [ts] Module '"c:/Temp/test/node_modules/@types/lodash/toSafeInteger/index"' resolves to a non-module entity and cannot be imported using this construct.
import toSafeInteger from 'lodash/toSafeInteger' // [ts] Module '"c:/Temp/test/node_modules/@types/lodash/toSafeInteger/index"' has no default export.
import { toSafeInteger } from 'lodash/toSafeInteger' // [ts] Module '"c:/Temp/test/node_modules/@types/lodash/toSafeInteger/index"' resolves to a non-module entity and cannot be imported using this construct.

Oops. Maybe this approach is not ES6 compatible?

@andraaspar Thank you for researching that. I like the lodash approach.
So in our case, hyperscript.d.ts could look like:
import { Hyperscript } from "./";
declare const h: Hyperscript;
export = h;

I think streams should be kept in a sub-folder but I'm not sure what the layout should be. Mithril has not yet decided how to package streams for script usage.
I'm going to be a little too busy to work on this much today, but hopefully will have some time on the weekend. Feel free to try out any module rearrangements if you have some time. :)

I've added all the submodules to the improved branch and I've updated my old tests to compile with the new types style.
The streams are laid out as they are currently in the mithril repo.
Haven't actually tried using this in a project yet, but I'll try to get to that this week.

@spacejack You have applied the right solution. Adding a const to the module fixes the compile for ES6. Great!

I've updated the readme in that branch with various component type examples.
Thinking about the FactoryComponent... I think we could omit the Vnode.state type from it since the point of it is to allow the closure to hold your state. So the FactoryComponent type would become:
export type FactoryComponent<A> = (vnode: Vnode<A, {}>) => Component<A, {}>

and usage would be:
const c = function c() {
	return {
		view ({attrs: {title}}) {
			return m('h2', title)
		}
	}
} as FactoryComponent<{title: string}>

The factory style is flexible, so you can still have a state type if you need it by using this style.

I went ahead and made the change to FactoryComponent.
I've also added your tests to the test-api.ts.

@spacejack Sorry for the delay in answering, things were getting a bit busy around here.
It's looking good I think... The only weird bit is how we have ./stream/index.d.ts but ./hyperscript.d.ts. Maybe it should be ./stream.d.ts? (Or everything should have its own folder, and named index.d.ts...)

I guess I thought about it differently because stream must be imported as a separate module (not included on m) unlike the rest of the sub modules.

True.

@spacejack Can you confirm that when using the improved branch in a different project, you can actually access the interfaces in the Mithril namespace? I have tried many things, on different computers, but it does not seem to work. Example:
import * as m from 'mithril'

var App: Mithril.Comp<{}, {}> = { // [ts] Cannot find namespace 'Mithril'.
	view() {
		return m('div', 'Hello World!')
	}
}
m.mount(document.body, App)

For reference, the lodash library has the same issue.

@spacejack Oh. It's all m.Comp now.

Yeah, the readme in improved branch shows some example usage. So you can also `import {Comp} from 'mithril'.


Websocket support for Transcribe

Confirm by changing [ ] to [x] below:

[x] I've gone though Developer Guide and API reference
[x] I've searched for previous similar issues and didn't find any solution

Platform/OS/Hardware/Device
Rasperry PI 4
Describe the question
Transcribe has support for WebSockets. However, the C++ SDK only seems to support HTTP/2. Are there any plans to add WebSockets support to the Transcribe API?
I'm asking because right now I'm getting this error message when I use TranscribeStreamingService:
Exception name: BadRequestException
Error message: A complete signal was sent without the preceding empty frame.

This error seems to be related to HTTP/2, so I wanted to give WebSockets a try.
Thanks!

Hi @dschnabel ,
Sorry for the delayed response, could you give me a bit more details on what you're trying to do and how you are trying to accomplish it?
A code snippet or better yet a quick sample code on the call you are trying to do would help me get a better idea of how this should work.

Hi @KaibaLopez I'm working on a chatbot and was using TranscribeStreamingService to stream the audio data to Transcribe in real-time. However, this was super slow and prone to errors (probably because TranscribeStreamingService uses HTTP/2) so I implemented my own methods to talk to the Transcribe API using WebSocket which works great.
Streaming via Websocket is much faster than HTTP/2 but unfortunately the C++ SDK doesn't support websockets. It would be nice if future versions of TranscribeStreamingService supported Websocket. Does this make sense?

@dschnabel ,
Yea ok, that does make sense.
It sounds like you got an implementation of websockets working though, could you share how you did that? Or better yet, make a PR on it so we could review the changes.

I didn't use the C++ SDK but went direcly so you'll have to rewrite the code to fit the SDK infrastructure.
Anyway, here's the code: https://gist.github.com/dschnabel/9b4ca0d6afd510b59e49c5cf1013087a
The file CRC.h is found under https://github.com/d-bahr/CRCpp/blob/master/inc/CRC.h
Usage:
#include "TranscribeManager.hpp"

// get signed URL
const string url = TranscribeManager::getSignedWebsocketUrl(accessKey_, secretKey_, region_);

// connect to the url using a socket library (e.g. https://github.com/machinezone/IXWebSocket)

// build request string
string request;
TranscribeManager::makeRequest(request, audioData); // audioData is a const vector<uint8_t>

// send request to socket

@jbmcgee Establishing a WSS connection is out of scope for this discussion. I used IXWebSocket which works on Windows as well. You can find sample code on the project page.


C# Built-in Timers Keeps Working Even if Script's node Got Freed

Godot version:
3.2.3.stable.mono / 3.2.4.beta4.mono
OS/device including version:
All
Issue description:
C# Built-in Timer keeps working in background even if the node attached to the script got reloaded/freed , sometimes it fires
E 0:00:45.219   godot_icall_2_93: Parameter "ptr" is null.
  <C++ Source>  modules/mono/glue/mono_glue.gen.cpp:898 @ godot_icall_2_93()
  <Stack Trace> :0 @ void Godot.NativeCalls.godot_icall_2_93(IntPtr , IntPtr , System.String , System.Object )()
                Object.cs:138 @ void Godot.Object.Set(System.String , System.Object )()
                (
                :0 @ void System.Timers.Timer.MyTimerCallback(System.Object )()
                :0 @ void System.Threading.Timer+Scheduler.TimerCB(System.Object )()
                :0 @ void System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()()
                :0 @ Boolean System.Threading.ThreadPoolWorkQueue.Dispatch()()
                :0 @ Boolean System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()()

Steps to reproduce:
Create a  Timer with AutoReset = true , Reload/Free the scene , the old Timer keeps Calling Elapsed beside the new created one from the new instance.
Minimal reproduction project:
GodotTimerIssue.zip

A simple approach to go over this is to call Timer.Dispose() in _ExitTree() Call .
e.g
public override void _ExitTree()
{
    MyTimer.Dispose();
}

cc @neikeq

Update :
This happens even if the timer is local variable , they don't get Disposed after Freeing a scene or reload.

That is the expected behaviour for a .net Timer.
The Object is kept alive, even if the variable or the containing object goes out of scope.
This does not only happen in Godot, it also happens in a Console-Application or Winforms-Application (See example below)
I don't think it is reasonable possible for Godot to find and Dispose all IDisposeables.
In the case below, the Timer variable goes out of scope and the Timer is no longer accessible by normal means.
It only exists somewhere in the runtime memory. Even if the Timer is somehow pulled out of the runtime memory, it would be hard to guess if the timer is still required or just dangling in the air.
Example of the Behaviour in a .net Console Application:
    static void Main(string[] args)
    {
        TestTimer();
        Console.WriteLine("Timer Variable is out of scope, but the object is still alive");
        Console.ReadLine();
    }

    static void TestTimer()
    {
        Timer t = new Timer(5000);
        t.Enabled = true;
        t.Elapsed += OnTick;
    }

    private static void OnTick(object sender, ElapsedEventArgs e)
    {
        Console.WriteLine("Tick");
    }

Will produce this output:

Timer Variable is out of scope, but the object is still alive
Tick
Tick
Tick

The one who creates the IDisposeable object is usually responsible to also call Dispose
(Your override _ExitTree() seems like a good solution)
See: https://docs.microsoft.com/en-us/dotnet/api/system.timers.timer?view=net-5.0#remarks

This type implements the IDisposable interface. When you have finished using the type, you should dispose of it either directly or indirectly.

Instead of a .net Timer, maybe a Godot coroutine would be a good solution?
I am not sure, but maybe it is possible to combine this: https://docs.godotengine.org/en/3.2/getting_started/scripting/c_sharp/c_sharp_differences.html#yield
await ToSignal(timer, "timeout");
GD.Print("After timeout");

And this: https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html#coroutines-signals
# Wait 5 seconds, then resume execution.
yield(get_tree().create_timer(5.0), "timeout")

Should look like this in c#
//Wait 5 seconds, then resume execution.
await ToSignal (GetTree().CreateTimer (5, false), "timeout");

Closing as working as intended, as explained by @Tobi-Mob. Thanks!


Strip HTML from action data

On load, strip HTML from action data (from CSV), e.g. descriptions.

Duplicates #380


Add axiom of function extensionality to pervasives

This adds the following axiom (slightly simplified; the actual implementation has a workaround for an issue with triggers):
  #[verifier(external_body)]
  pub proof fn fun_ext<A, B>(f1: FnSpec(A) -> B, f2: FnSpec(A) -> B)
    requires forall |x| f1(x) === f2(x)
    ensures f1 === f2
  {}

Thanks for the reviews!


[ENG-1069] Add SSO Users Connected panel to institutional users dashboard

Ticket: ENG-1069
Feature flag: Institutional Dashboard

Purpose
To show the number of SSO users connected on the Institutional Users Dashboard.
Summary of Changes
Added ssoUsersConnected to institution's stat summary. Updated styles for panels on the institutional users dashboard. Added SSO users connected to the page.

Pull Request Test Coverage Report for Build 3552

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 75.595%

Totals

Change from base Build 3550:
0.0%

Covered Lines:
8026

Relevant Lines:
9313

💛  - Coveralls

Also, if you wouldn't mind resolving the changelog conflict.


[Webhooks][Addsection][1820324]

Added section. Please review.

Docs Build status updates of commit c669482:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 9bcf564:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit fe6e137:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 2feb40a:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 83b20fe:
:warning: Validation status: warnings

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:warning:Warning
View
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md

Line 104, Column 57: [Warning-file-not-found] Invalid file link: '~/task-modules-and-cards/cards/cards-format'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit e03fcf3:
:warning: Validation status: warnings

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:warning:Warning
View
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md

Line 104, Column 57: [Warning-file-not-found] Invalid file link: '../task-modules-and-cards/cards/cards-format'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit da45dc6:
:warning: Validation status: warnings

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:warning:Warning
View
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md

Line 104, Column 57: [Warning-file-not-found] Invalid file link: '~task-modules-and-cards/cards/cards-format.md'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 132d897:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit d4d9cce:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit b383e2e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/webhooks-and-connectors/how-to/add-outgoing-webhook.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


[Question] - Running app without ngrok tunnel

Hi @achuvm,
Another question.
Is it possible to run the Viro library without ngrok at all?
Thanks,
Tom

Hi @dittmarconsulting,
Yes, it's possible to run Viro w/o ngrok.
If you're using the Viro Media App:
On iOS:

If your phone and computer are on the same network, you can type in your local IP address.

On Android:

You can also use your local IP address.
You can reverse tether using the command adb reverse tcp:8081 tcp:8081 and simply use the localhost address: <IP_ADDRESS> in the Viro Media App.

If you're building your app through Xcode:

in AppDelegate.m, change the line BOOL usingNgrok = YES; to BOOL usingNgrok = NO;, this will default to using local IP (this is automatically detected and "sent" to the built app).

If you're building your app through Android Studio:

You should reverse tether using the command adb reverse tcp:8081 tcp:8081 and simply build and run the application.

Let me know if you need help or more clarification!
Andy

Thank you very much for the fast reply.
I was after the Xcode switch but I'm sure others will be interested in the other solutions as well.
It's especially important to turn off the tunnel to enable remote debugging unless that's possible with ngrok.
Thanks again,
Tom

I'm assuming that ngrok will not on release/production builds - how is that configuration handled?  Is that in the docs somewhere?

Hi @mypark,
The use of a packager server vs bundled Javascript assets is a feature of React Native. We just added the ngrok bit to overcome a few issues, but the deployment/release process is the same as React Native.
Instructions for Android can be found here:
https://facebook.github.io/react-native/docs/signed-apk-android.html
iOS:
I can't find the instructions for iOS, but they're the same as any other iOS app out there, simply change the Scheme's Build Configuration to Release:
https://stackoverflow.com/questions/5706548/how-do-i-create-a-release-build-in-xcode
Let us know if you have any issues


Manual benchmarks for PQClean

In order to compare to PQclean, I've replicated the manual benchmark approach for PQClean.
Note that the PQClean has internal randomness generation, compared to us, so I wonder if we should not include sampling the randomness in our part of the benchmark. We did not do this with the criterion benchmarks, so I didn't do it here for now.
Also, I've split the parameter set benchmarks, so you can run them individually. The bit where I include bench_utils.rs via #[path=...] is a bit nasty, let me know if I should try a different approach.
Fixes #487

I wonder if we should not include sampling the randomness in our part of the benchmark

Yeah we should measure all the combinations eventually. Can you put that on an issue?


15ml / 50ml tube rack container file fix

from OT user Magnus: 'I think there is a bug in the containers file for the tube-rack-15_50mL for positions C1 and C2. The x position should be 64, not 54. (Compare to the 32 of the B1 and B2)'

@andySigler

fixed here:
https://github.com/OpenTrons/opentrons-api/commit/e2dca6d7d06808298de27ac0222640d6764b3228


chore(package): update kronos-service to version 4.13.1

Codecov Report

Merging #152 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #152   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           2      2
  Lines           7      7
=====================================
  Hits            7      7

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 c935458...900d059. Read the comment docs.

Coverage remained the same at 100.0% when pulling 900d059de5d36ad0b3554b7a50dce02f131b1469 on greenkeeper/kronos-service-4.13.1 into c9354585c7954ca05ed57d3bd754f24cfa912f49 on master.

Coverage remained the same at 100.0% when pulling 900d059de5d36ad0b3554b7a50dce02f131b1469 on greenkeeper/kronos-service-4.13.1 into c9354585c7954ca05ed57d3bd754f24cfa912f49 on master.


Goal Hint Improvements

Add actions that allow easy insertion and deletion of goal hints. Also, goal hints now work for non tactic mode. After this, goal hints branch can be deleted.

goal hints is no longer relevant branch


chore: v1.0.2

:robot: I have created a release beep boop
1.0.2 (2023-10-08)
Bug Fixes

Disable @typescript-eslint/no-dynamic-delete rule (26fd5d2)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Wondermarin/eslint-config/releases/tag/v1.0.2 :sunflower:


Would It Be Possible To Be Able To Specify Which Branch(es) To Publish?

I'm currently using two Command Line tasks to sync my VSTS Git repo to GitHub, one to pull from the GitHub repo and the other to push to it.
I was hoping to be able to replace them with your task, but I can't see a way to specify which branch(es) to sync. I have both a development branch and a master branch, but I only want to sync the master branch to GitHub.
Am I missing something, or was the intent behind your extension to publish all branches? If so, would it be possible to add the ability to select which branch(es) to publish?

It currently publishes all branches. I would happily accept a pull request for this.

OK, I'll see what I can do - thanks!


Add bulk secrets api

Description
This allows getting all secrets through the bulk secrets API
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #25
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[ ] Created/updated tests
[x] Extended the documentation

Codecov Report

Merging #26 (81509c3) into main (936a393) will decrease coverage by 0.39%.
The diff coverage is 41.17%.

@@             Coverage Diff              @@
##               main      #26      +/-   ##
============================================
- Coverage     68.28%   67.88%   -0.40%
- Complexity      396      403       +7
============================================
  Files            45       45
  Lines          1400     1417      +17
============================================
+ Hits            956      962       +6
- Misses          444      455      +11

Impacted Files
Coverage Δ
Complexity Δ

src/lib/Secret.php
52.17% <41.17%> (-47.83%)
8.00 <7.00> (+7.00)
:arrow_down:

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 936a393...81509c3. Read the comment docs.

Codecov Report

Merging #26 (81509c3) into main (936a393) will decrease coverage by 0.39%.
The diff coverage is 41.17%.

@@             Coverage Diff              @@
##               main      #26      +/-   ##
============================================
- Coverage     68.28%   67.88%   -0.40%
- Complexity      396      403       +7
============================================
  Files            45       45
  Lines          1400     1417      +17
============================================
+ Hits            956      962       +6
- Misses          444      455      +11

Impacted Files
Coverage Δ
Complexity Δ

src/lib/Secret.php
52.17% <41.17%> (-47.83%)
8.00 <7.00> (+7.00)
:arrow_down:

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 936a393...81509c3. Read the comment docs.


Provide a wrapper / helper to run Neomake automatically

Currently the README suggests the following to enable automatic checking:
autocmd! BufWritePost * Neomake

This is a bit brittle though, e.g. it will also run on :w /some/other/path, but on the current file.
I've created https://github.com/neomake/neomake/issues/404 as a first step into this direction.

I also get this issue,should we use <afile> instead? also :wa command should not only check current buffer.
BTW we should provid a g:var for user do not run maker when use  :wq command!
what do you think?

Yes, we should provide some function for this.
Here is what I am currently using: https://github.com/blueyed/dotfiles/commit/0c69796bb44674403ddb240be3475f04e0be9934.
expand("<afile>") seems to refer to the relative file, while expand("<amatch>") refers to the full path always.

BTW we should provid a g:var for user do not run maker when use :wq command!

That is not so easy I think, but we might be able to use QuitPre here and mark the window/buffer as not going to be processed.

I am reading syntasc source code,and try to find a way to implement it.

Something like this maybe? https://github.com/blueyed/dotfiles/commit/4c59098cc42766f61f7f67169fdf8d90bb8437cd

#1167

Closing in favor of #1167.


Add xinxin game generator

Xinxin game generator with built in tests to ensure xinxin and OpenSpiel agree on the state of the game.

@googlebot I consent.


Anvil logo click area break with Foundry VTT version 9

In the new-ish Foundry VTT version 9 (tested with build 242), the logo click area is broken. On the initial first right-click on the anvil icon, the right-hand sidebar gets bumped further to the left. The bullseye click area seems to be the far right of the screen now, for some reason.
Somewhat related to #2, I should investigate how that is implemented in the first place and either fix and offer an option to disable it, or just remove the anvil click area altogether.

Removed with 7df1c532dd3d2d31c84643c158fd3485756856d5.


Bump Kafka to version 3.3.1

Happy New Year!
Best wishes for 2023.
Big thanks for this cool project.
May I ask if it is possible to bump the Kafka version up to the latest (as of this writing) which is 3.3.1 please?
Thank you!

Hello and Happy new year!
Although 2024 seems a bit far but thanks for the wishes!
The version for Kafka is now set to 3.3.1.

Typo corrected.
Many thanks for the bump!
Best wishes for 2023!

Much appreciated for this I have been looking for a simple docker Kafka without Zookeeper and allows me to create topics in the config. Yours meets all those requirements so thank you!


ci(e2e): adjust playwright config

Motivation
We want to add more devices to the tests and adjust different timeouts so we can handle them in a better way.
Changes

added macOS config
added more devices
added timeouts

Tests

tested on branch

okay so I break it up into 3 different PRs. Screenshots will be automatically added with the update-snapshots workflow after everything is merged no?

after everything is merged no?

you should run it manually on your branch before merging, as test to see if everything works correctly

broken up into 3 different PRs


avoid launching both chief and worker pods when running a non distributed job

when triggering a non distributed job in kubeflow it will create two pods(1 worker, 1 chief).
This will fix that.

This change is

/assign @wbuchwalter

/assign @r2d4


use mixlib-cli's deprecation mechanism

Description
Deprecation logic is now available in mixlib-cli
via deprecated_option.  Let's use that instead
of keeping our custom deprecation behavior.
Signed-off-by: Marc A. Paradise<EMAIL_ADDRESS>Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[x] Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have run the pre-merge tests locally and they pass.
[ ] (na) I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] All commits have been signed-off for the Developer Certificate of Origin.

Looking into the test failures. The two in application_spec are related.

The test failure is resolved with https://github.com/chef/mixlib-cli/pull/66

kitchen failures were caused by a mis-tag of ohai 15.0.39.  I created tag v15.0.39 which should resolve that.


Update aches.json

Marrying the cat would be amazing just because

its impossible to get the ach :cat_nerd:

What if just saying "Cat I do" gives the achievement

no

make the ach id be styled correctly
add hints or change the way you get it (e.g. "cat do you want to marry me?", just saying "Cat i do" without context is weird)
move it further down in the file
actually code it. if you wont this should go to #ach-ideas in cat stand

marriage is literally spelled wrong

closing for stale


Feature Request: Code Splitting Analyzer

Hi all!
Just wondering if this is the right place to ask if people see the need for a linting rule to detect code splitting opportunity.
For example, the following code shows that OptionA and OptionB are conditionally needed, so that's an opportunity for code splitting.
import OptionA from './OptionA'
import OptionB from './OptionB'

function Component() {
  return option === 'a' ? <OptionA /> : <OptionB />
}

Is there a similar tool available already? If not, I'm interested in developing one!
Thank you!

Can you elaborate on what you mean by "code splitting"?
In this example, the advantages of not loading both components up front have to be weighed against the costs of making another http request, and the UX cost of the delay that's visible to the user. It does not strike me as a decision that should be encouraged by tooling.

Hey @ljharb ! Thanks so much for your quick feedback!
Ah yes, I think the intention is to flag possible code splitting (dynamic import) opportunities at develop time.
But like you said, the engineers will still need to decide if it's the right decision to code split based on the criteria you listed. And if it's not, then a eslint-ignore comment can be added to let other engineers know it's an explicit decision to not code split.
Not sure if the linter is the right place for this, just wanted to reuse the AST and also provide feedback to engineers in real time!

I think you could make a custom rule, but I'm very skeptical of its utility, especially since the majority of cases it identifies (in my experience) would not be good places to do code splitting.

That's a really good point! Sounds like the rule will need to be smarter, otherwise it will just introduce too much false positive and overwhelm people 🤔
I've never built a linter rule before, how difficult is it to build a prototype to test/tweak this?
I'm thinking we'll need to be able to identify import statement, dynamic import, ternary, and if block to start with?
I guess the pain point I'm trying to address is engineers importing functions and components that are gated behind feature flags or infrequent behaviors (say, only render a calculator when a user clicks on the show calculator button, but only 20% users do so)
So right now it's through training and code reviews to help prevent the bundle bloat. But I wanted to see if it's possible to make the process easier through tools.
Or what other ways have you found effective in addressing the problems?
Thanks again for the awesome feedback!

I’ve not found anything other than code review as an effective tool here - it’s also notable that most apps don’t need any form of code splitting; it’s only very large ones where it starts to be helpful, and you can go a very long way with a small number of manual splits.

Right! We're splitting the app at least by routes and feature flags now, although code review has missed a few ones that we only caught later
I think I'll try to find some time to build a prototype for this custom rule to test it next week and report back how it goes!
Thanks again for your time, Jordan 🤩🙏

Hey @ljharb ! Sorry just circling back to this. I haven't had time to actively look into this given the workload changes and priority shifting from COVID-19 🙏
I'm happy to reopen a new issue or just follow up on this thread later. But for issue hygiene, should we close this issue for now?
Thank you!

I think it's fine to leave it open until you have time to follow up on it; issue hygiene isn't about open issue count, it's about making sure issue statuses are accurate :-)

Haha okay that makes sense 🤩Thanks again and stay healthy!

Closing for now :-) happy to reopen if there's something to do here.


[Identity] Update azure-identity to pass next-pylint

Quite a number of updates to be made, with most of them being related to docstrings.

@xiangyan99 I can take the first crack at this.

Closed via https://github.com/Azure/azure-sdk-for-python/pull/30869


hash.txt from rar2john

hash.txt
I using RAR5 version , someone put a password on the rar and he total scam me he didn't bring me the password what is the chance this git may crack it?
this is what I get from rar2john

This is not a password cracking service.


feat: generate all accents

Changes the border color from "blue" to your chosen accent color.

Thank you for the fast answer and for merging! Have a great day. :)


maybe path "TCPIP*" is missing in beacons

I'm not sure but shouldn't the path "TCPIP*" be used for IP forwarding packets?
Compared to other gateways, the LoRa iGate lacks this.
Just look at the raw packets at OE5XPM-10 at https://aprs-map.info/.
I have added the path and the icon appears.

"TCPIP*" should be used in case you want to forward from one server to another.
the current implementation was done with the aprs spec.


CARDS-2075: The PrintHeader UIX and JSX code are fetched every time the form menu is opened or closed

To test CARDS-2075:

start in prems mode
create a form
on the form page in view mode, open and close the action menu (the one next to the pencil, with Print Preview | Export as text | Delete form), monitoring the network request
observe if each opening and closing triggers a request for /apps/cards/ExtensionPoints/PrintHeader and /libs/cards/resources/patient-portal.PrintHeader.XYZ.js

What if, instead of all of these changes that pull the extensions all the time whether we're going to use them or not, we only render the PrintPreview component once open is true? or we only pull the extensions in the PrintPreview component when open becomes true?

In dev the extensions are pulled in the PrintPreview component each when open becomes true. Since we use Popover component to display buttons, we destroy and recreate all of it's children on open event, which forces extensions re-fetching.

Ctrl+P doesn't trigger the print preview on a form page

I see why. I removed { !actionsMenu &&
{ dropdownList }
 } from the Form.
However, rendering a stack of components just to hold one key down listener in not the best design either.

Re-implemented fix, now we fetch the extensions not from within the PrintPreview component, but statically outside the component as @sdumitriu proposed.

What if, instead of all of these changes that pull the extensions all the time whether we're going to use them or not, we only render the PrintPreview component once open is true? or we only pull the extensions in the PrintPreview component when open becomes true?

In dev the extensions are pulled in the PrintPreview component each time when open becomes true. Since we use Popover component to display buttons, we destroy and recreate all of it's children on open event, which forces extensions re-fetching.

That's not quite the same. In dev we load the extentsions whenever the component is mounted, not when open becomes true. I've illustrated my suggestion in this commit on the CARDS-2075_alt branch (no PR yet, it's for debate purposes only).
So to sum up:

in dev, the header extensions are fetched every time the dropdown menu is open - not good
in this branch, they are fetched once when we render the form (which renders the PrintButton which renders the preview), regardless whether the print preview is ever shown or not - better than dev
in CARDS-2075_alt the extensions are fetched only if print preview is actually opened, but will be refetched every time we open print preview - also better than dev in a different way.

I'm ok with either 2 or 3, they're both improvements.

Ctrl+P doesn't trigger the print preview on a form page

I see why. I removed { !actionsMenu &&
{ dropdownList }
 } from the Form. However, rendering a stack of dropdownList  components just to hold one key down listener in not the best design either. Imho it has to be refactored as well.

It doesn't need a huge refactoring actually, the improvement can be as simple as #1337.

It doesn't need a huge refactoring actually, the improvement can be as simple as https://github.com/data-team-uhn/cards/pull/1337.

I do not think the https://github.com/data-team-uhn/cards/pull/1337 addresses what I mean here. My point is not that we render dropdownList - it is not rendered twice in dev. If dropdownList is rendered twice, removing the line would not cause the regression of Ctrl+P. The PR is the optimisation but rendering is not happennig twice.
What i mean in rendering dropdownList with all its buttons if !actionsMenu with display: none just to accomodate one keydown listener.

It doesn't need a huge refactoring actually, the improvement can be as simple as #1337.

I do not think the #1337 addresses what I mean here. My point is not that we render dropdownList - it is not rendered twice in dev. If dropdownList is rendered twice, removing the line would not cause the regression of Ctrl+P. The PR is the optimisation but rendering is not happennig twice.
What i mean in rendering dropdownList with all its buttons if !actionsMenu with display: none just to accomodate one keydown listener.

One key listener - for now. Ideally we should have keyboard shortcuts for all actions.

That's not quite the same. In dev we load the extensions whenever the component is mounted, not when open becomes true.

Right, I mean Popover's open property, not the PrintPreview open prop, sorry for the confusion. On the opening of the Popover all of it's children getting mounted and unmounted on close, which triggered excessive extension fetching on each Popover open.


Package metadata

I would like haddock to be aware of at least rudimentary package metadata.  As as a start the package name of what is being build. The rationale for that is splitting the haddocks generated content page (the tree of modules) into a list of trees one per package.   The simple way to solve this is to pass --package-name & --package-version to haddock which would be written to the interface file file; when haddock generates the content page it reads the interface files it would know which interfaces comes from which package:
I have a draft pr where I infer package names from interface file names.

@Kleidukos let me know what do you think.  Here's a print screen of what I have so far:

I think it would be nice to also print package version next to its name.

Related to haskell/cabal#7669.

@coot I love it.


Lumpy error (TypeError: %d format)

Hi,
I'm trying to run the structural variation pipeline with lumpy. I'm getting an error when lumpy is run. Running manually the call to lumpyexpress gets the error below. I've tried both the development and the stable versions, and getting the same error.

Sourcing executables from /home/ebendavid/bcbio/anaconda/bin/lumpyexpress.config ...
Checking for required python modules (/home/ebendavid/bcbio/anaconda/bin/python)...
create temporary directory

Calculating insert distributions...
Library read groups: N203
Library read length: 101
/home/ebendavid/bcbio/anaconda/lib/python2.7/site-packages/numpy/core/_methods.py:59: RuntimeWarning: Mean of empty slice.
warnings.warn("Mean of empty slice.", RuntimeWarning)
/home/ebendavid/bcbio/anaconda/lib/python2.7/site-packages/numpy/core/_methods.py:70: RuntimeWarning: invalid value encountered in double_scalars
ret = ret.dtype.type(ret / rcount)
Traceback (most recent call last):
File "/home/ebendavid/bcbio/anaconda/share/lumpy-sv-0.2.13-0/scripts/pairend_distro.py", line 106, in
(removed, upper_cutoff))
TypeError: %d format: a number is required, not numpy.float64

Eyal;
Sorry about the issues, this error with lumpy is typically due to problems with the input data. It's trying to calculate details on paired end reads and not finding enough information to correctly calculate. You could try replacing /home/ebendavid/bcbio/anaconda/share/lumpy-sv-0.2.13-0/scripts/pairend_distro.py with the latest script:
https://github.com/arq5x/lumpy-sv/blob/master/scripts/pairend_distro.py
to see if it behaves better or provides additional details about what might be happening. If that helps at all we could update the lumpy conda package but it's worth checking if it's a sample quality issue first. Hope this helps.

Hi,
Thanks for the help. The only thing I can think of re my data is that it is super high coverage (several 100x). could that be an issue for lumpy?
I'm trying the new pairend_distro file and will let you know. Thanks!

Hi,
I used the new version of the script and it now progressed further, and got stuck on error: missing pair end parameters mean stdev
Thanks!
Eyal

[2017-08-26T19:57Z] Running LUMPY...
[2017-08-26T19:57Z] /home/ebendavid/bcbio/anaconda/bin/lumpy
[2017-08-26T19:57Z]     -t /home/ebendavid/bcbiotx/tmph7Ck8E/3-sort-svs.vcf
[2017-08-26T19:57Z]     -msw 4
[2017-08-26T19:57Z]     -tt 0
[2017-08-26T19:57Z]
[2017-08-26T19:57Z]      -pe bam_file:/home/ebendavid/align/3/3-sort-disc.bam,histo_file:/
home/ebendavid/bcbiotx/tmph7Ck8E/3-sort-svs.vcf.sample1.lib1.x4.histo,mean:NA,stdev:NA,read_len
gth:101,min_non_overlap:101,discordant_z:5,back_distance:10,weight:1,id:3,min_mapping_threshold:20,read_group:3
3
[2017-08-26T19:57Z]      -sr bam_file:/home/ebendavid/align/3/3-sort-sr.bam,back_distance:
10,min_mapping_threshold:20,weight:1,id:3,min_clip:20
[2017-08-26T19:57Z]     > /home/ebendavid/bcbiotx/tmpM8jSm0/3-sort-svs.vcf
[2017-08-26T19:57Z] missing pair end parameters:mean stdev

Well, reading through this error again I figure out I made my sample.csv file incorrectly, and so bcbio was treating it as single end (looking at the config file revealed that).

Thanks much for debugging and following up with the underlying issue. Glad it all got sorted out and hopefully the re-run works as expected.


wip: nested multi select + product page categories management

WIP
https://user-images.githubusercontent.com/16856471/222190128-6dd25985-e6aa-42c2-9b1b-c8d6541d77b2.mov

RESOLVES CORE-1105

closing in favor of https://github.com/medusajs/medusa/pull/3401


Add support for drag & drop to the List component

Added support for drag & drop to the List component. Fixes #428 .
All sections using the List component (Skills, Hobbies, Certifications, Projects, etc.) will now support drag & drop.

Wow, that was very quick, and the code looks pristine. Really amazing work, truly. Will have this reviewed and deployed as soon as I get some leeway.
In the mean time, do you perhaps have a PayPal or donation link where I could send money to you, as a thank you? I am just astounded by the level of commitment you have for Reactive Resume and so glad that you share my vision of wanting to help people.

Thanks for the appreciation. It is nice to know that you are happy with the work :-) For me this is also a way to practice some new technical skills that I wanted to learn since some time but never had the chance or time to. So it is a way to help other people and help me too :-) I haven't got an account to receive donations at the moment but I'm looking at setting one up in due course.

Thanks for the appreciation. It is nice to know that you are happy with the work :-) For me this is also a way to practice some new technical skills that I wanted to learn since some time but never had the chance or time to. So it is a way to help other people and help me too :-) I haven't got an account to receive donations at the moment but I'm looking at setting one up in due course.


[ocilib] Update to 4.7.5

[X] Changes comply with the maintainer guide
[X] SHA512s are updated for each updated download
[X] The "supports" clause reflects platforms that may be fixed by this new version
[X] Any fixed CI baseline entries are removed from that file.
[X] Any patches that are no longer applied are deleted from the port's directory.
[X] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[X] Only one version is added to each modified port's versions file.

@microsoft-github-policy-service agree

@jalegido Do not reply, you need to leave a commant.

@microsoft-github-policy-service agree


Onboarding 1: Create Innovation Hub experimental cluster

Description
Prepare a Google Kubernetes Engine experimental cluster and deploy an ODA Canvas, following the instructions at: https://github.com/tmforum-oda/oda-canvas/tree/master/installation (contribute enhancements to installation where issues are found using the https://github.com/tmforum-oda/oda-ca-docs/blob/master/ContributionsGuide.md ).
As preparation for this, review the documentation site at https://tmforum-oda.github.io/oda-ca-docs/ (particularly the introduction section and demo videos).  The source material should be treated as a beta level of robustness; Teams should troubleshoot issues, reach out for help if required, and contribute back any enhancements (even for enhancements to documentation to make it easier for others to install).

I tried the installation instruction with Kubernetes v1.27 and the deployed component custom-resource did not get handled by the webhook. The DEPLOYMENT_STATE is empty forever.
Using Kubernetes v1.25 everything works as expected.

If the external IP is for keycloak is not needed, the keycloak service can be changed from LoadBalancer to ClusterIP with the following helm-value:
helm upgrade --install canvas -n canvas --create-namespace --set keycloak.service.type=ClusterIP .

The problem is, that we have a quota on 8 External IPs and one is for istio and if the second is for keycloak, we have a limit of four clusters.


Try focusing input and window Linux - Does not work

For: https://keybase.atlassian.net/browse/DESKTOP-301
Does not fix it. :(

This is meant to show off, not to merge.
@keybase/react-hackers

Does isfocused() return false?

What about autofocus flag on a plain input tag (not material Ui)
On Monday, January 25, 2016, Marco Munizaga<EMAIL_ADDRESS>wrote:

This is meant to show off, not to merge.
@keybase/react-hackers
https://github.com/orgs/keybase/teams/react-hackers
—
Reply to this email directly or view it on GitHub
https://github.com/keybase/client/pull/1828#issuecomment-174801064.

browserwindow.isFocused() returns false, even after calling browserwindow.focus()


[WIP](Depends on #12836) Dto collection save inventory specs for acyclic graph of dto collections

Specs for save_inventory with testing data dependencies forming directed acyclic graph

@miq-bot assign @agrare


Support custom NAPALM drivers (e.g. Huawei VRP)

Hi, we run eBGP on few Huawei VRP devices and it's would be great if PM would support it.
There is already  installed napalm-huawei-vrp library, but with zero effect :(

The current supported platforms is a hard-coded list which corresponds to NAPALM base supported drivers. To support community drivers, platforms list must be changeable by users with a field to give the name of the NAPALM driver to user for each platform.

The current supported platforms is a hard-coded list which corresponds to NAPALM base supported drivers. To support community drivers, platforms list must be changeable by users with a field to give the name of the NAPALM driver to user for each platform.

You are right, in the same Netbox this is exactly what was done - when you manually add Device Platform, you manually enter name of the napalm driver and when accessing a device, napalm load a library with that name

You are right, in the same Netbox this is exactly what was done - when you manually add Device Platform, you manually enter name of the napalm driver and when accessing a device, napalm load a library with that name

We use Nokia SROS for some peering edge, I would like to see the ability to add Napalm drivers too, so far I hacked together an ansible playbook to pull the config from peering-manager and deploy. I'm only using this in a lab today, needs lots more testing before I will trust it with production.


Hide Jobs folder if pgagent extension is not installed

This is a continuation of #6077.
Currently, we show the Jobs folder even if the mentioned extension is not installed.
In order to hide it, we need to load a list of extensions (which requires progress monitor) during the expansion of the parent node.

Also case from https://github.com/dbeaver/dbeaver/issues/21919

Maybe add a checkbox to settings? ))

fixed in #22826

Returned back.