[IMPROVEMENT]   CRD version webhook for longhorn.io/v1beta1 and longhorn.io/v1beta2

Is your improvement request related to a feature? Please describe
To avoid the CR operation crash using different CRD version APIs, we need a CRD version conversion mechanism for v1beta1 and v1beta2.
Describe the solution you'd like
Add CRD conversion webhook for longhorn.io/v1beta1 and longhorn.io/v1beta2.
Ref:

https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/#specify-multiple-versions
https://book.kubebuilder.io/multiversion-tutorial/conversion-concepts.html

Depends:

https://github.com/longhorn/longhorn/issues/2955

Reference the command on how to access different API version https://github.com/kubernetes/kubernetes/issues/87231#issuecomment-574731190

Hey team! Please add your planning poker estimate with ZenHub @derekbit @jenting @joshimoo @shuo-wu

Leave a note here:
We will check and upgrade the API version for existing CRs here: https://github.com/longhorn/longhorn-manager/blob/2a9411bf733e33c13355c907f05bf7df1fc5dd5e/upgrade/upgrade.go#L180

Hey team! Please add your planning poker estimate with ZenHub @PhanLe1010 @c3y1huang

Leaving a note here.
We need to consider if the users still use v1beta1 to operate CR.
Furthermore, we can't rely the E2E test to cover this since currently E2E test isn't create/get/update/delete from CR directly. And, only engineers know which fields changed from v1beta1 to v1beta2.

Leaving a note here.
After applying #2955, the conditions cannot be retrieved correctly.
root@ku60-master:~# kl get --raw /apis/longhorn.io/v1beta1/nodes/
{"apiVersion":"longhorn.io/v1beta1","items":[{"apiVersion":"longhorn.io/v1beta1","kind":"Node","metadata":{"creationTimestamp":"2021-11-23T07:37:48Z","finalizers":["longhorn.io"],"generation":1,"name":"ku60-worker1","namespace":"longhorn-system","resourceVersion":"24111","uid":"21c5b03d-882a-49ff-9922-6d7f58af52ce"},"spec":{"allowScheduling":true,"disks":{"default-disk-745ff2be8d312b52":{"allowScheduling":true,"evictionRequested":false,"path":"/var/lib/longhorn/","storageReserved":39667363430}},"engineManagerCPURequest":0,"evictionRequested":false,"name":"ku60-worker1","replicaManagerCPURequest":0,"tags":[]},"status":{"conditions":[{},{},{}],"diskStatus":{"default-disk-745ff2be8d312b52":{"conditions":[{},{}],"diskUUID":"047b4a94-861f-40a7-bb2d-75d39fef430d","scheduledReplica":{"pvc-fbd6fcbd-02e8-42aa-bf65-cafb6d51e153-r-5104c9a6":2147483648},"storageAvailable":126248550400,"storageMaximum":132224544768,"storageScheduled":2147483648}},"region":"","zone":""}},{"apiVersion":"longhorn.io/v1beta1","kind":"Node","metadata":{"creationTimestamp":"2021-11-23T07:37:45Z","finalizers":["longhorn.io"],"generation":1,"name":"ku60-master","namespace":"longhorn-system","resourceVersion":"24661","uid":"5c4b04a6-de27-496f-9a14-29fc7e4860c1"},"spec":{"allowScheduling":true,"disks":{"default-disk-745ff2be8d312b52":{"allowScheduling":true,"evictionRequested":false,"path":"/var/lib/longhorn/","storageReserved":39667363430}},"engineManagerCPURequest":0,"evictionRequested":false,"name":"ku60-master","replicaManagerCPURequest":0,"tags":[]},"status":{"conditions":[{},{},{}],"diskStatus":{"default-disk-745ff2be8d312b52":{"conditions":[{},{}],"diskUUID":"b0a8d517-0f8f-4912-a3af-784cdc8b914b","scheduledReplica":{"pvc-fbd6fcbd-02e8-42aa-bf65-cafb6d51e153-r-4ae12cce":2147483648},"storageAvailable":120691097600,"storageMaximum":132224544768,"storageScheduled":2147483648}},"region":"","zone":""}}],"kind":"NodeList","metadata":{"continue":"","resourceVersion":"24935"}}
root@ku60-master:~# kl get --raw /apis/longhorn.io/v1beta2/nodes/
{"apiVersion":"longhorn.io/v1beta2","items":[{"apiVersion":"longhorn.io/v1beta2","kind":"Node","metadata":{"creationTimestamp":"2021-11-23T07:37:48Z","finalizers":["longhorn.io"],"generation":1,"name":"ku60-worker1","namespace":"longhorn-system","resourceVersion":"24111","uid":"21c5b03d-882a-49ff-9922-6d7f58af52ce"},"spec":{"allowScheduling":true,"disks":{"default-disk-745ff2be8d312b52":{"allowScheduling":true,"evictionRequested":false,"path":"/var/lib/longhorn/","storageReserved":39667363430}},"engineManagerCPURequest":0,"evictionRequested":false,"name":"ku60-worker1","replicaManagerCPURequest":0,"tags":[]},"status":{"conditions":[{"lastProbeTime":"","lastTransitionTime":"2021-11-23T07:37:49Z","message":"","reason":"","status":"True","type":"MountPropagation"},{"lastProbeTime":"","lastTransitionTime":"2021-11-23T13:03:32Z","message":"Kubernetes node ku60-worker1 not ready: NodeStatusUnknown","reason":"KubernetesNodeNotReady","status":"False","type":"Ready"},{"lastProbeTime":"","lastTransitionTime":"2021-11-23T07:37:48Z","message":"","reason":"","status":"True","type":"Schedulable"}],"diskStatus":{"default-disk-745ff2be8d312b52":{"conditions":[{"lastProbeTime":"","lastTransitionTime":"2021-11-23T08:15:24Z","message":"Disk default-disk-745ff2be8d312b52(/var/lib/longhorn/) on node ku60-worker1 is ready","reason":"","status":"True","type":"Ready"},{"lastProbeTime":"","lastTransitionTime":"2021-11-23T08:15:24Z","message":"Disk default-disk-745ff2be8d312b52(/var/lib/longhorn/) on node ku60-worker1 is schedulable","reason":"","status":"True","type":"Schedulable"}],"diskUUID":"047b4a94-861f-40a7-bb2d-75d39fef430d","scheduledReplica":{"pvc-fbd6fcbd-02e8-42aa-bf65-cafb6d51e153-r-5104c9a6":2147483648},"storageAvailable":126248550400,"storageMaximum":132224544768,"storageScheduled":2147483648}},"region":"","zone":""}},{"apiVersion":"longhorn.io/v1beta2","kind":"Node","metadata":{"creationTimestamp":"2021-11-23T07:37:45Z","finalizers":["longhorn.io"],"generation":1,"name":"ku60-master","namespace":"longhorn-system","resourceVersion":"24661","uid":"5c4b04a6-de27-496f-9a14-29fc7e4860c1"},"spec":{"allowScheduling":true,"disks":{"default-disk-745ff2be8d312b52":{"allowScheduling":true,"evictionRequested":false,"path":"/var/lib/longhorn/","storageReserved":39667363430}},"engineManagerCPURequest":0,"evictionRequested":false,"name":"ku60-master","replicaManagerCPURequest":0,"tags":[]},"status":{"conditions":[{"lastProbeTime":"","lastTransitionTime":"2021-11-23T07:37:45Z","message":"","reason":"","status":"True","type":"MountPropagation"},{"lastProbeTime":"","lastTransitionTime":"2021-11-23T08:15:38Z","message":"Node ku60-master is ready","reason":"","status":"True","type":"Ready"},{"lastProbeTime":"","lastTransitionTime":"2021-11-23T07:37:45Z","message":"","reason":"","status":"True","type":"Schedulable"}],"diskStatus":{"default-disk-745ff2be8d312b52":{"conditions":[{"lastProbeTime":"","lastTransitionTime":"2021-11-23T08:15:28Z","message":"Disk default-disk-745ff2be8d312b52(/var/lib/longhorn/) on node ku60-master is ready","reason":"","status":"True","type":"Ready"},{"lastProbeTime":"","lastTransitionTime":"2021-11-23T08:15:28Z","message":"Disk default-disk-745ff2be8d312b52(/var/lib/longhorn/) on node ku60-master is schedulable","reason":"","status":"True","type":"Schedulable"}],"diskUUID":"b0a8d517-0f8f-4912-a3af-784cdc8b914b","scheduledReplica":{"pvc-fbd6fcbd-02e8-42aa-bf65-cafb6d51e153-r-4ae12cce":2147483648},"storageAvailable":120691097600,"storageMaximum":132224544768,"storageScheduled":2147483648}},"region":"","zone":""}}],"kind":"NodeList","metadata":{"continue":"","resourceVersion":"24960"}}

Discuss with @derekbit
The conversion also needs a webhook server. Therefore, this issue needs to tackle along with #3241.

Did a test, using the v1beta1 to access the CR, the result works well except the value of status.conditions is empty.
kubectl get volumes.v1beta1.longhorn.io -n longhorn-system -o yaml
kubectl get engineimages.v1beta1.longhorn.io -n longhorn-system -o yaml
kubectl get backuptargets.v1beta1.longhorn.io -n longhorn-system -o yaml
kubectl get nodes.v1beta1.longhorn.io -n longhorn-system -o yaml

Validation - FAILED
Bump in problem when there is Volume or BackingIamge CR from previous version(v1.1.3, V1.2.3)
time="2022-01-13T08:55:49Z" level=error msg="error decoding src object" error="v1beta2.Node.Status: v1beta2.NodeStatus.Conditions: []v1beta2.Condition: decode slice: expect [ or n, but found {, error found in #10 byte of ...|ditions\":{},\"diskSta|..., bigger context ...|rCPURequest\":0,\"tags\":[]},\"status\":{\"conditions\":{},\"diskStatus\":{\"default-disk-e22d292bdb653860\":{\"|..."
time="2022-01-13T08:55:50Z" level=error msg="error decoding src object" error="v1beta2.Volume.Status: v1beta2.VolumeStatus.Conditions: []v1beta2.Condition: decode slice: expect [ or n, but found {, error found in #10 byte of ...|ditions\":{},\"current|..., bigger context ...|t\":\"\",\"sourceVolume\":\"\",\"state\":\"\"},\"conditions\":{},\"currentImage\":\"longhornio/longhorn-engine:v1.2.|..."

time="2022-01-13T08:04:50Z" level=error msg="error decoding src object" error="v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects \" or n, but found {, error found in #10 byte of ...|8e38764\":{},\"43a26f2|..., bigger context ...|{\"disks\":{\"3bded216-b728-4a58-9483-3b7998e38764\":{},\"43a26f28-8a30-458c-b383-aa6f9965b977\":{},\"d1a20|..."

I did a test with Volume CR and upgrade from v1.2.3 to master-head several times :thinking:

Validation - FAILED
Bump in problem when there is Volume or BackingIamge CR from previous version(v1.1.3, V1.2.3)
time="2022-01-13T08:55:49Z" level=error msg="error decoding src object" error="v1beta2.Node.Status: v1beta2.NodeStatus.Conditions: []v1beta2.Condition: decode slice: expect [ or n, but found {, error found in #10 byte of ...|ditions\":{},\"diskSta|..., bigger context ...|rCPURequest\":0,\"tags\":[]},\"status\":{\"conditions\":{},\"diskStatus\":{\"default-disk-e22d292bdb653860\":{\"|..."
time="2022-01-13T08:55:50Z" level=error msg="error decoding src object" error="v1beta2.Volume.Status: v1beta2.VolumeStatus.Conditions: []v1beta2.Condition: decode slice: expect [ or n, but found {, error found in #10 byte of ...|ditions\":{},\"current|..., bigger context ...|t\":\"\",\"sourceVolume\":\"\",\"state\":\"\"},\"conditions\":{},\"currentImage\":\"longhornio/longhorn-engine:v1.2.|..."

time="2022-01-13T08:04:50Z" level=error msg="error decoding src object" error="v1beta2.BackingImage.Spec: v1beta2.BackingImageSpec.Disks: ReadString: expects \" or n, but found {, error found in #10 byte of ...|8e38764\":{},\"43a26f2|..., bigger context ...|{\"disks\":{\"3bded216-b728-4a58-9483-3b7998e38764\":{},\"43a26f28-8a30-458c-b383-aa6f9965b977\":{},\"d1a20|..."

I did a test with Volume CR and upgrade from v1.2.3 to master-head several times :thinking:

To clarify the testing environment:

local k3s 1.21.x with 1+3 nodes(VMs)
fresh install v1.1.3 and v1.2.3
deploy simple pod with pvc from examples/
then upgrade to master via kubectl apply

The master version I was using is from longhorn-manager/deploy/install
I am now able to isolate the steps to reproduce the problem:

launch a fresh k3s cluster
install v1.1.3
deploy in-cluster nfs using: longhorn/deploy/backupstores/nfs-backupstore.yaml
update backup target setting
deploy example pod and voluem: longhorn/examples/pod_with_pvc.yaml
set up 1 or more recurring jobs
upgrade to master head

longhorn-manager 2022/01/14 06:40:31 proto: duplicate proto type registered: VersionResponse
longhorn-manager W0114 06:40:31.999710       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
longhorn-manager time="2022-01-14T06:40:32Z" level=info msg="cannot list the content of the src directory /var/lib/rancher/longhorn/engine-binaries for the copy, will do nothing: Failed to execute: nsenter [--mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net bash -c ls /var/lib/rancher/longhorn/engine-binaries/*], output , stderr, ls: cannot access '/var/lib/rancher/longhorn/engine-binaries/*': No such file or directory\n, error exit status 2"
longhorn-manager I0114 06:40:32.099748       1 leaderelection.go:242] attempting to acquire leader lease  longhorn-system/longhorn-manager-upgrade-lock...
longhorn-manager I0114 06:40:32.308131       1 leaderelection.go:252] successfully acquired lease longhorn-system/longhorn-manager-upgrade-lock
longhorn-manager time="2022-01-14T06:40:32Z" level=info msg="Start upgrading"
longhorn-manager time="2022-01-14T06:40:32Z" level=info msg="No API version upgrade is needed"
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Starting storageClass recurring job translation" namespace=longhorn-system translate=storage-class-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Finished storageClass recurring job translation" namespace=longhorn-system translate=storage-class-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Starting volume recurring job translation" namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Creating backup-3-b5f4656e-77074ba4 recurring job CR" action=create-recurringJob-CRs namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=debug msg="upgrade from v1.1.0 to v1.2.0: Checking if backup-3-b5f4656e-77074ba4 recurring job CR already exists" action=create-recurringJob-CRs namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=debug msg="upgrade from v1.1.0 to v1.2.0: Recurring job CR already exists &{{ } {backup-3-b5f4656e-77074ba4  longhorn-system /apis/longhorn.io/v1beta2/namespaces/longhorn-system/recurringjobs/backup-3-b5f4656e-77074ba4 abc11e41-e5fb-4060-a56b-628ad04da23a 6736 1 2022-01-14 06:39:21 +0000 UTC <nil> <nil> map[] map[] [] []  [{longhorn-manager Update longhorn.io/v1beta2 2022-01-14 06:39:21 +0000 UTC FieldsV1 &FieldsV1{Raw:*[123 34 102 58 115 112 101 99 34 58 123 34 46 34 58 123 125 44 34 102 58 99 111 110 99 117 114 114 101 110 99 121 34 58 123 125 44 34 102 58 99 114 111 110 34 58 123 125 44 34 102 58 110 97 109 101 34 58 123 125 44 34 102 58 114 101 116 97 105 110 34 58 123 125 44 34 102 58 116 97 115 107 34 58 123 125 125 44 34 102 58 115 116 97 116 117 115 34 58 123 34 46 34 58 123 125 44 34 102 58 111 119 110 101 114 73 68 34 58 123 125 125 125],}}]} {backup-3-b5f4656e-77074ba4 [] backup * * * * ? 3 10 map[]} {}}" action=create-recurringJob-CRs namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Updating pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed volume labels to map[longhornvolume:pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed recurring-job.longhorn.io/backup-3-b5f4656e-77074ba4:enabled]" action=convert-volume-recurring-jobs-to-labels namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=error msg="Upgrade failed: upgrade CRD failed: upgrade from v1.1.0 to v1.2.0: upgrade recurring jobs failed: upgrade from v1.1.0 to v1.2.0: translate volume recurringJobs failed: upgrade from v1.1.0 to v1.2.0: convert volume recurring jobs to labels failed: failed to update pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed volume: Volume.longhorn.io \"pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed\" is invalid: spec.replicaAutoBalance: Unsupported value: \"\": supported values: \"ignored\", \"disabled\", \"least-effort\", \"best-effort\""
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="Upgrade leader lost: c1-control"
longhorn-manager time="2022-01-14T06:40:33Z" level=fatal msg="Error starting manager: upgrade CRD failed: upgrade from v1.1.0 to v1.2.0: upgrade recurring jobs failed: upgrade from v1.1.0 to v1.2.0: translate volume recurringJobs failed: upgrade from v1.1.0 to v1.2.0: convert volume recurring jobs to labels failed: failed to update pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed volume: Volume.longhorn.io \"pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed\" is invalid: spec.replicaAutoBalance: Unsupported value: \"\": supported values: \"ignored\", \"disabled\", \"least-effort\", \"best-effort\""
Stream closed EOF for longhorn-system/longhorn-manager-hbpgx (wait-longhorn-webhook)
Stream closed EOF for longhorn-system/longhorn-manager-hbpgx (longhorn-manager)

If create a backing image before step 7 (upgrade to master), the backing image will bump into problem first:
longhorn-manager 2022/01/14 07:20:02 proto: duplicate proto type registered: VersionResponse
longhorn-manager W0114 07:20:02.188558       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
longhorn-manager time="2022-01-14T07:20:02Z" level=info msg="cannot list the content of the src directory /var/lib/rancher/longhorn/engine-binaries for the copy, will do nothing: Failed to execute: nsenter [--mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net bash -c ls /var/lib/rancher/longhorn/engine-binaries/*], output , stderr, ls: cannot access '/var/lib/rancher/longhorn/engine-binaries/*': No such file or directory\n, error exit status 2"
longhorn-manager I0114 07:20:02.211812       1 leaderelection.go:242] attempting to acquire leader lease  longhorn-system/longhorn-manager-upgrade-lock...
longhorn-manager time="2022-01-14T07:20:02Z" level=info msg="New upgrade leader elected: c1-worker2"
longhorn-manager I0114 07:20:05.142244       1 leaderelection.go:252] successfully acquired lease longhorn-system/longhorn-manager-upgrade-lock
longhorn-manager time="2022-01-14T07:20:05Z" level=info msg="Start upgrading"
longhorn-manager time="2022-01-14T07:20:05Z" level=info msg="Upgrading from longhorn.io/v1beta1 to longhorn.io/v1beta2"
longhorn-manager I0114 07:20:07.418203       1 request.go:621] Throttling request took 1.227589714s, request: PUT:https://<IP_ADDRESS>:443/apis/longhorn.io/v1beta1/namespaces/longhorn-system/backingimagemanagers/backing-image-manager-7298-6068
longhorn-manager time="2022-01-14T07:20:07Z" level=error msg="Upgrade failed: upgrade API version failed: fix up CRs: failed: conversion webhook for longhorn.io/v1beta1, Kind=BackingImage failed: Post https://longhorn-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s: EOF"
longhorn-manager E0114 07:20:07.531132       1 leaderelection.go:360] Failed to update lock: Put "https://<IP_ADDRESS>:443/apis/coordination.k8s.io/v1/namespaces/longhorn-system/leases/longhorn-manager-upgrade-lock": context canceled
longhorn-manager I0114 07:20:07.531915       1 leaderelection.go:277] failed to renew lease longhorn-system/longhorn-manager-upgrade-lock: timed out waiting for the condition
longhorn-manager E0114 07:20:07.539304       1 leaderelection.go:300] Failed to release lock: Operation cannot be fulfilled on leases.coordination.k8s.io "longhorn-manager-upgrade-lock": the object has been modified; please apply your changes to the latest version and try again
longhorn-manager time="2022-01-14T07:20:07Z" level=info msg="Upgrade leader lost: c1-worker1"
longhorn-manager time="2022-01-14T07:20:07Z" level=fatal msg="Error starting manager: upgrade API version failed: fix up CRs: failed: conversion webhook for longhorn.io/v1beta1, Kind=BackingImage failed: Post https://longhorn-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s: EOF"
Stream closed EOF for longhorn-system/longhorn-manager-4kdl8 (wait-longhorn-webhook)
Stream closed EOF for longhorn-system/longhorn-manager-4kdl8 (longhorn-manager)

Detail of the volume.longhorn.io CR:
Name:         pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d
Namespace:    longhorn-system
Labels:       longhornvolume=pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d
Annotations:  <none>
API Version:  longhorn.io/v1beta2
Kind:         Volume
Metadata:
  Creation Timestamp:  2022-01-14T06:33:05Z
  Finalizers:
    longhorn.io
  Generation:  4
  Managed Fields:
    API Version:  longhorn.io/v1beta1
    Fields Type:  FieldsV1
    fieldsV1:
      f:metadata:
        f:finalizers:
          .:
          v:"longhorn.io":
        f:labels:
          .:
          f:longhornvolume:
      f:spec:
      f:status:
    Manager:         longhorn-manager
    Operation:       Update
    Time:            2022-01-14T06:33:05Z
  Resource Version:  374075
  UID:               a7118924-1f04-4760-88f0-65c0889903ce
Spec:
  Standby:           false
  Access Mode:       rwo
  Backing Image:
  Base Image:
  Data Locality:     disabled
  Data Source:
  Disable Frontend:  false
  Disk Selector:
  Encrypted:          false
  Engine Image:       longhornio/longhorn-engine:v1.1.3
  From Backup:
  Frontend:           blockdev
  Last Attached By:
  Migratable:         false
  Migration Node ID:
  Node ID:            ip-10-33-0-41
  Node Selector:
  Number Of Replicas:  3
  Recurring Jobs:
    Concurrency:              0
    Cron:                     0 0 * * *
    Name:                     c-ovrr92
    Retain:                   20
    Task:                     backup
  Replica Auto Balance:
  Revision Counter Disabled:  false
  Size:<PHONE_NUMBER>
  Stale Replica Timeout:      2880
Status:
  Actual Size:  51003392
  Clone Status:
    Snapshot:
    Source Volume:
    State:
  Conditions:
    Last Probe Time:
    Last Transition Time:  2022-01-14T06:33:05Z
    Message:
    Reason:
    Status:                False
    Type:                  restore
    Last Probe Time:
    Last Transition Time:  2022-01-14T06:33:05Z
    Message:
    Reason:
    Status:                True
    Type:                  scheduled
    Last Probe Time:
    Last Transition Time:  2022-01-14T06:33:05Z
    Message:
    Reason:
    Status:                False
    Type:                  toomanysnapshots
  Current Image:           longhornio/longhorn-engine:v1.1.3
  Current Node ID:         ip-10-33-0-41
  Expansion Required:      false
  Frontend Disabled:       false
  Is Standby:              false
  Kubernetes Status:
    Last PVC Ref At:
    Last Pod Ref At:
    Namespace:        default
    Pv Name:          pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d
    Pv Status:        Bound
    Pvc Name:         longhorn-simple-pvc
    Workloads Status:
      Pod Name:          longhorn-simple-pod
      Pod Status:        Running
      Workload Name:
      Workload Type:
  Last Backup:
  Last Backup At:
  Last Degraded At:
  Owner ID:              ip-10-33-0-41
  Pending Node ID:
  Remount Requested At:
  Restore Initiated:     false
  Restore Required:      false
  Robustness:            healthy
  Share Endpoint:
  Share State:
  State:                 attached
Events:
  Type    Reason    Age   From                               Message
  ----    ------    ----  ----                               -------
  Normal  Detached  19m   longhorn-volume-controller         volume pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d has been detached
  Normal  Start     19m   longhorn-kubernetes-pv-controller  Persistent Volume pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d started to use/reuse Longhorn volume pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d
  Normal  Attached  19m   longhorn-volume-controller         volume pvc-f3ebe33e-ceac-4e4b-9a5b-535edd71c16d has been attached to ip-10-33-0-41

Note here
v113 both RJ and BI CR will have problem
v123 seems only backing image

The master version I was using is from longhorn-manager/deploy/install
I am now able to isolate the steps to reproduce the problem:

launch a fresh k3s cluster
install v1.1.3
deploy in-cluster nfs using: longhorn/deploy/backupstores/nfs-backupstore.yaml
update backup target setting
deploy example pod and voluem: longhorn/examples/pod_with_pvc.yaml
set up 1 or more recurring jobs
upgrade to master head

longhorn-manager 2022/01/14 06:40:31 proto: duplicate proto type registered: VersionResponse
longhorn-manager W0114 06:40:31.999710       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
longhorn-manager time="2022-01-14T06:40:32Z" level=info msg="cannot list the content of the src directory /var/lib/rancher/longhorn/engine-binaries for the copy, will do nothing: Failed to execute: nsenter [--mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net bash -c ls /var/lib/rancher/longhorn/engine-binaries/*], output , stderr, ls: cannot access '/var/lib/rancher/longhorn/engine-binaries/*': No such file or directory\n, error exit status 2"
longhorn-manager I0114 06:40:32.099748       1 leaderelection.go:242] attempting to acquire leader lease  longhorn-system/longhorn-manager-upgrade-lock...
longhorn-manager I0114 06:40:32.308131       1 leaderelection.go:252] successfully acquired lease longhorn-system/longhorn-manager-upgrade-lock
longhorn-manager time="2022-01-14T06:40:32Z" level=info msg="Start upgrading"
longhorn-manager time="2022-01-14T06:40:32Z" level=info msg="No API version upgrade is needed"
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Starting storageClass recurring job translation" namespace=longhorn-system translate=storage-class-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Finished storageClass recurring job translation" namespace=longhorn-system translate=storage-class-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Starting volume recurring job translation" namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Creating backup-3-b5f4656e-77074ba4 recurring job CR" action=create-recurringJob-CRs namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=debug msg="upgrade from v1.1.0 to v1.2.0: Checking if backup-3-b5f4656e-77074ba4 recurring job CR already exists" action=create-recurringJob-CRs namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=debug msg="upgrade from v1.1.0 to v1.2.0: Recurring job CR already exists &{{ } {backup-3-b5f4656e-77074ba4  longhorn-system /apis/longhorn.io/v1beta2/namespaces/longhorn-system/recurringjobs/backup-3-b5f4656e-77074ba4 abc11e41-e5fb-4060-a56b-628ad04da23a 6736 1 2022-01-14 06:39:21 +0000 UTC <nil> <nil> map[] map[] [] []  [{longhorn-manager Update longhorn.io/v1beta2 2022-01-14 06:39:21 +0000 UTC FieldsV1 &FieldsV1{Raw:*[123 34 102 58 115 112 101 99 34 58 123 34 46 34 58 123 125 44 34 102 58 99 111 110 99 117 114 114 101 110 99 121 34 58 123 125 44 34 102 58 99 114 111 110 34 58 123 125 44 34 102 58 110 97 109 101 34 58 123 125 44 34 102 58 114 101 116 97 105 110 34 58 123 125 44 34 102 58 116 97 115 107 34 58 123 125 125 44 34 102 58 115 116 97 116 117 115 34 58 123 34 46 34 58 123 125 44 34 102 58 111 119 110 101 114 73 68 34 58 123 125 125 125],}}]} {backup-3-b5f4656e-77074ba4 [] backup * * * * ? 3 10 map[]} {}}" action=create-recurringJob-CRs namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="upgrade from v1.1.0 to v1.2.0: Updating pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed volume labels to map[longhornvolume:pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed recurring-job.longhorn.io/backup-3-b5f4656e-77074ba4:enabled]" action=convert-volume-recurring-jobs-to-labels namespace=longhorn-system translate=volume-recurring-jobs
longhorn-manager time="2022-01-14T06:40:33Z" level=error msg="Upgrade failed: upgrade CRD failed: upgrade from v1.1.0 to v1.2.0: upgrade recurring jobs failed: upgrade from v1.1.0 to v1.2.0: translate volume recurringJobs failed: upgrade from v1.1.0 to v1.2.0: convert volume recurring jobs to labels failed: failed to update pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed volume: Volume.longhorn.io \"pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed\" is invalid: spec.replicaAutoBalance: Unsupported value: \"\": supported values: \"ignored\", \"disabled\", \"least-effort\", \"best-effort\""
longhorn-manager time="2022-01-14T06:40:33Z" level=info msg="Upgrade leader lost: c1-control"
longhorn-manager time="2022-01-14T06:40:33Z" level=fatal msg="Error starting manager: upgrade CRD failed: upgrade from v1.1.0 to v1.2.0: upgrade recurring jobs failed: upgrade from v1.1.0 to v1.2.0: translate volume recurringJobs failed: upgrade from v1.1.0 to v1.2.0: convert volume recurring jobs to labels failed: failed to update pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed volume: Volume.longhorn.io \"pvc-4cc3667e-a101-44ca-8fa3-85784ee42bed\" is invalid: spec.replicaAutoBalance: Unsupported value: \"\": supported values: \"ignored\", \"disabled\", \"least-effort\", \"best-effort\""
Stream closed EOF for longhorn-system/longhorn-manager-hbpgx (wait-longhorn-webhook)
Stream closed EOF for longhorn-system/longhorn-manager-hbpgx (longhorn-manager)

This is because when crdAPIVersion == "", v1beta1.FixupCRs(config, namespace, lhClient) will not be executed, crdAPIVersion == "" actually means two cases: fresh install (v1beta2) or upgrade (v1beta1) and the current implementation partially missed the upgrade case, so there is no CR fixing if it's the upgrade case.

Need to fix doAPIVersionUpgrade to resolve the problem I described above
Also need to spec.replicaAutoBalance: Unsupported value: \"\": supported values: \"ignored\", \"disabled\", \"least-effort\", \"best-effort\"" in fixupVolumes to make "" to ignored.

If create a backing image before step 7 (upgrade to master), the backing image will bump into problem first:
longhorn-manager 2022/01/14 07:20:02 proto: duplicate proto type registered: VersionResponse
longhorn-manager W0114 07:20:02.188558       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
longhorn-manager time="2022-01-14T07:20:02Z" level=info msg="cannot list the content of the src directory /var/lib/rancher/longhorn/engine-binaries for the copy, will do nothing: Failed to execute: nsenter [--mount=/host/proc/1/ns/mnt --net=/host/proc/1/ns/net bash -c ls /var/lib/rancher/longhorn/engine-binaries/*], output , stderr, ls: cannot access '/var/lib/rancher/longhorn/engine-binaries/*': No such file or directory\n, error exit status 2"
longhorn-manager I0114 07:20:02.211812       1 leaderelection.go:242] attempting to acquire leader lease  longhorn-system/longhorn-manager-upgrade-lock...
longhorn-manager time="2022-01-14T07:20:02Z" level=info msg="New upgrade leader elected: c1-worker2"
longhorn-manager I0114 07:20:05.142244       1 leaderelection.go:252] successfully acquired lease longhorn-system/longhorn-manager-upgrade-lock
longhorn-manager time="2022-01-14T07:20:05Z" level=info msg="Start upgrading"
longhorn-manager time="2022-01-14T07:20:05Z" level=info msg="Upgrading from longhorn.io/v1beta1 to longhorn.io/v1beta2"
longhorn-manager I0114 07:20:07.418203       1 request.go:621] Throttling request took 1.227589714s, request: PUT:https://<IP_ADDRESS>:443/apis/longhorn.io/v1beta1/namespaces/longhorn-system/backingimagemanagers/backing-image-manager-7298-6068
longhorn-manager time="2022-01-14T07:20:07Z" level=error msg="Upgrade failed: upgrade API version failed: fix up CRs: failed: conversion webhook for longhorn.io/v1beta1, Kind=BackingImage failed: Post https://longhorn-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s: EOF"
longhorn-manager E0114 07:20:07.531132       1 leaderelection.go:360] Failed to update lock: Put "https://<IP_ADDRESS>:443/apis/coordination.k8s.io/v1/namespaces/longhorn-system/leases/longhorn-manager-upgrade-lock": context canceled
longhorn-manager I0114 07:20:07.531915       1 leaderelection.go:277] failed to renew lease longhorn-system/longhorn-manager-upgrade-lock: timed out waiting for the condition
longhorn-manager E0114 07:20:07.539304       1 leaderelection.go:300] Failed to release lock: Operation cannot be fulfilled on leases.coordination.k8s.io "longhorn-manager-upgrade-lock": the object has been modified; please apply your changes to the latest version and try again
longhorn-manager time="2022-01-14T07:20:07Z" level=info msg="Upgrade leader lost: c1-worker1"
longhorn-manager time="2022-01-14T07:20:07Z" level=fatal msg="Error starting manager: upgrade API version failed: fix up CRs: failed: conversion webhook for longhorn.io/v1beta1, Kind=BackingImage failed: Post https://longhorn-webhook.longhorn-system.svc:9443/v1/webhook/conversion?timeout=30s: EOF"
Stream closed EOF for longhorn-system/longhorn-manager-4kdl8 (wait-longhorn-webhook)
Stream closed EOF for longhorn-system/longhorn-manager-4kdl8 (longhorn-manager)

Detail of the volume.longhorn.io CR:

☝ this is due to the webhook server is not ready so any resource update will not work, but right now the webhook server should be ensured to start before running the longhorn manager pod, so this should probably be that the webhook server is down after the longhorn manager pod started. Not sure why. However, the longhorn manager will be restarted w/ the webhook server together, so it will work at the end.
@derekbit need your help to follow up and fix this. Thank you. (overall, the conversion is working, because here the issue is actually not hit the conversion part yet. The previous comments from @kaxing seems due to incorrect CRDs installation, but again not quite sure. Let's follow up the following testing)

This is because when crdAPIVersion == "", v1beta1.FixupCRs(config, namespace, lhClient) will not be executed, crdAPIVersion == "" actually means two cases: fresh install (v1beta2) or upgrade (v1beta1) and the current implementation partially missed the upgrade case, so there is no CR fixing if it's the upgrade case.

Actually, the CRD upgrade from v1beta1 to v1beta2 is executed. The empty string of volume.spec. replicaAutoBalance in another place leads to the crash of the longhorn-manager and runs upgrade again and again.

this seems probably due to the webhook server is not ready afterwards so any resource update will not work

Right, the uninitialized variable results in the backingImage conversion failure.

Actually, the CRD upgrade from v1beta1 to v1beta2 is executed. The empty string of volume.spec. replicaAutoBalance in another place leads to the crash of the longhorn-manager and runs upgrade again and again.

Thanks for the update 👍
Another thing to clarify, as per https://github.com/longhorn/longhorn/issues/3265#issuecomment-1012841277, in the first part log, it mentioned No API version upgrade is needed" which should mean the resources upgrade did not get executed, right? but in the second part log, the resource upgrade actually got executed as expected.

For the first test in #3265 (comment), the v1beta1->v1beta2 upgrade  is successful, and APIVersion is already set to v1beta2. The longhorn-manager restarts after the conversion failure of volume.spec.replicaAutoBalance don't need run the v1beta1->v1beta2 upgrade logic.  Thus, we can see No API version upgrade is needed log message.
But in the second test, the v1beta1->v1beta2 upgrade logic always fails because of the failure of the backingImage update (conversion failure), so the update logic is always executed again after restart and we can see "Upgrading from longhorn.io/v1beta1 to longhorn.io/v1beta2".

For the first test in #3265 (comment), the v1beta1->v1beta2 upgrade is successful, and APIVersion is already set to v1beta2. The longhorn-manager restarts after the conversion failure of volume.spec.replicaAutoBalance don't need run the v1beta1->v1beta2 upgrade logic. Thus, we can see No API version upgrade is needed log message.
But in the second test, the v1beta1->v1beta2 upgrade logic always fails because of the failure of the backingImage update (conversion failure), so the update logic is always executed again after restart and we can see "Upgrading from longhorn.io/v1beta1 to longhorn.io/v1beta2".

Ah, I missed the context, thanks! No questions now. All good.

Plan to rerun the test once the rc1 image for v1.3.0 is out.

Validation - PASSED
Tested with latest master-head images(v1.3.0-dev* ).
No more CRD and conversion webhook related blockers for the following upgrade path:

v1.1.3 → v1.3.0-dev
v1.2.4 → v1.3.0-dev
v1.1.3 → v1.2.4 → v1.3.0-dev

A healthy conversion webhook logs:
time="2022-04-15T08:14:41Z" level=info msg="Starting longhorn conversion webhook server"
W0415 08:14:41.351399       1 client_config.go:552] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
time="2022-04-15T08:14:41Z" level=warning msg="Failed to init Kubernetes secret: secrets \"longhorn-webhook-tls\" not found"
time="2022-04-15T08:14:41Z" level=info msg="Listening on :9443"
time="2022-04-15T08:14:41Z" level=info msg="certificate CN=dynamic,O=dynamic signed by CN=dynamiclistener-ca,O=dynamiclistener-org: notBefore=2022-04-15 08:14:41 +0000 UTC notAfter=2023-04-15 08:14:41 +0000 UTC"
time="2022-04-15T08:14:41Z" level=info msg="Creating new TLS secret for longhorn-webhook-tls (count: 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=3F9BD4436518536EF3E083B5FE20827EC1D397ED]"
time="2022-04-15T08:14:41Z" level=error msg="failed to update cert with configured SANs: secrets \"longhorn-webhook-tls\" already exists"
time="2022-04-15T08:14:42Z" level=info msg="certificate CN=dynamic,O=dynamic signed by CN=dynamiclistener-ca,O=dynamiclistener-org: notBefore=2022-04-15 08:14:41 +0000 UTC notAfter=2023-04-15 08:14:42 +0000 UTC"
time="2022-04-15T08:14:42Z" level=info msg="Updating TLS secret for longhorn-webhook-tls (count: 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=51F9250ED767A51CE90E97509B6E0C8A241F67D6]"
time="2022-04-15T08:14:42Z" level=info msg="Active TLS secret longhorn-webhook-tls (ver=35259) (count 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=51F9250ED767A51CE90E97509B6E0C8A241F67D6]"
time="2022-04-15T08:14:42Z" level=info msg="Starting apiregistration.k8s.io/v1, Kind=APIService controller"
time="2022-04-15T08:14:42Z" level=info msg="Starting /v1, Kind=Secret controller"
time="2022-04-15T08:14:42Z" level=info msg="Starting apiextensions.k8s.io/v1, Kind=CustomResourceDefinition controller"
time="2022-04-15T08:14:42Z" level=info msg="Building conversion rules..."
time="2022-04-15T08:14:42Z" level=info msg="Update CRD for backingimages.longhorn.io"
time="2022-04-15T08:14:42Z" level=info msg="Updating TLS secret for longhorn-webhook-tls (count: 1): map[listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=51F9250ED767A51CE90E97509B6E0C8A241F67D6]"
time="2022-04-15T08:14:42Z" level=info msg="Update CRD for backuptargets.longhorn.io"
time="2022-04-15T08:14:42Z" level=info msg="Update CRD for engineimages.longhorn.io"
time="2022-04-15T08:14:42Z" level=info msg="Update CRD for nodes.longhorn.io"
time="2022-04-15T08:14:42Z" level=info msg="Update CRD for volumes.longhorn.io"
time="2022-04-15T08:14:47Z" level=info msg="Updating TLS secret for longhorn-webhook-tls (count: 2): map[listener.cattle.io/cn-longhorn-admission-webhook.longhor-59584d:longhorn-admission-webhook.longhorn-system.svc listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=XXXX460C54BDC031B]"
time="2022-04-15T08:14:47Z" level=info msg="Active TLS secret longhorn-webhook-tls (ver=35323) (count 2): map[listener.cattle.io/cn-longhorn-admission-webhook.longhor-59584d:longhorn-admission-webhook.longhorn-system.svc listener.cattle.io/cn-longhorn-conversion-webhook.longho-6a0089:longhorn-conversion-webhook.longhorn-system.svc listener.cattle.io/fingerprint:SHA1=82XXXX60C54BDC031B]"

* docker.io/longhornio/longhorn-manager@sha256:19a0eeb5c74506a18329f6aa13c910de4d16b4fd3ba241719918cb1c8c0f6b9b


[cluster-test] Refactor perf benchmarks in cluster-test into Experiments

Summary

At a high level: As we add more and more test cases to cluster-test, it becomes hard to squeeze all of them in main.rs. At a high level, this moves individual tests into individual Experiments and moves a few more functions away from main into other libraries
We construct ExperimentSuites with the list of Experiments required and then run those ExperimentSuite

Details:

Update experiment run to return an Option which is the result of an experiment

Some experiments will have results like perf results, some experiments will not like reboot random validators

Convert perf benchmarks into three separate experiments: PerformanceBenchmark, PerformanceBenchmarkNodesDown, PerformanceBenchmarkThreeRegionSimulation

This reduces the amount of code that we have to maintain in main.rs makes creating new experiment suites easier

Update new_pre_release which adds the performance experiments as well
Create a stats module which contains the queries for various stats like tps, latency, etc. Move code from main.rs to this module
Move activate_all, deactivate_all logic into effects module
Move emit_txn_for into tx_emitter module

Test Plan
Ran on my dev cluster

I wonder if we can unite Experiment and Benchmark?

Use same trait for both
Pass context to Experiment::run, e.g. Experiment::run(context: &mut Context)
In this context we can define bunch of things freaquently used in both experiments and perf bench:

- cluster
- prometheus
- executor

In addition to those things we can pass something like changelog_writer: Formatter.
Then when whatever experiment or benchmark wants to add some line to changelog report, it can use write!(&mut context.changelog_writer, "...", ...)

So, I am not distinguishing b/w a Benchmark and an Experiment. A Benchmark is just another Experiment and uses the same trait.

Pass context to Experiment::run, e.g. Experiment::run(context: &mut Context)

This seems like a good idea as it avoids having these things as part of the individual experiment struct.

In addition to those things we can pass something like changelog_writer: Formatter.

I think its simpler if the Experiment::run returns an Option<String> which represents any output we might want to display from the Experiment run.

@bors-libra r+
Thank you!

:pushpin: Commit b37da5b has been approved by andll

:hourglass: Testing commit d936085545343eee1fe680f1dcb359e91944bf1a with merge 20dc691cb025bc5ed0672d4cbc9d463037e83e22...

:sunny: Test successful - checks-circle_commit_workflow
State: approved= try=False


Support for QuickPay API v10

ActiveMerchant (AM) currently supports QuickPay API v7 and we need to also support v10 - that is both versions should be supported at the same time. Which version to use should be configurable for every AM user.
I'm not sure how to do this. A Shopify guy mentioned that "AM requests a md5 checksum and it should be possible to use the same mechanism to ask for API-version".

already done


Update our automated end to end test to include adding a degree and contact details

This PR addresses a couple of things that slipped through the cracks when we added contact details (#103) and degrees (#114). It

adds these pages to the end to end spec
fixes a minor bug in the code and a bit of copy-pasta in the specs

The second commit addresses a Rubocop violation from #112 — feeling the lack of CI here! It probably needs the eye of @kjdchapman.

Merging. This should fix the build errors due to Rubocop on other branches


[WIP] Make reverse mapping available for Resource.

Current coverage is 99.35% (diff: 100%)

Merging #3 into master will decrease coverage by 0.64%

@@           master         #3   diff @@
========================================
  Files           5          5
  Lines         146        154     +8
  Methods         0          0
  Messages        0          0
  Branches        0          0
========================================
+ Hits          146        153     +7
- Misses          0          1     +1
  Partials        0          0

Powered by Codecov. Last update a816fa5...3ff999f

Closed by #10.


init config : isAudio : wrong default value; custom value not applied

In jeelizFaceExpressions.js isAudio is set to true by default:
...,rotate:0,isAudio:!0,disableRendering:!1...

Also it is not reassigned to config value in init(config) function or anywhere else in lib code.
So lib is asking not only for a camera access, but also for a microphone

isAudio is set to true by default by choice, because JeelizWeboji may be used for karaoke or avatar video conferencing webapps that require audio access.
It can be reassigned, you just need to set videoSettings: {isAudio: false} in the init options. In the Three.js helper for example it is set to false by default ( https://github.com/jeeliz/jeelizWeboji/blob/74e638d3bca03bae8ea1bf089fc2b3099a0b73b5/helpers/three/JeelizWebojiThreeHelper.js#L32 ). In the raccoon demo the audio access is then not requested.

My fault, thought isAudio should be on the same level as videoSettings, not inside it.
Thanks!


entry.data() just returns no data just "627 bytes"

my code:
for entry in archive.entries(version: .current) {
        // Get basic entry information
        let name = try entry.getName()
        let size = try entry.stat().size
        print("\(name) -> \(size as Any)")

        // Read entry contents into a `Data` instance
        let data = try entry.data()
        print(data)
    }

results:
➜  MyAppSwift swift run MyAppSwift
[2/2] Merging module MyAppSwift
document.json -> Optional(627)
627 bytes
pages/DD2372FD-EEFA-4F85-BDBD-D24EF3C1E124.json -> Optional(22888)
22888 bytes

this should return the contents of the file not the file size or am I doing something wrong here?

Hey! Sorry for the late response. The function should return the Data instance containing entry data. Please check Data APIs like withUsafeBytes to access the underlying bytes.


Add license headers to files identified by the Fossology scan

Detailed fossology report available in STL-398
Signed-off-by: kulkarniamol<EMAIL_ADDRESS>

I've added a comment to the jira asking how we can have fossology ignore the false positives noted in the review comments. https://jira.hyperledger.org/browse/STL-398

This PR needs to be rebased and the conflicts resolved. There are also a lot of comments that haven't been addressed as well. Could this PR be reduced to the pieces that are not contentious so that we can get the bulk of it merged in?


[FR]: Design overhaul

Contact Details
imed#8086
Present your request
Intro
This is kind of a big issue, regrouping everything about the plugin design, to avoid further visual issues about supporting other themes and to also avoid mobile visual problems.
I have no experience in CSS, but when I compare this plugin to the kanban plugin or the projects plugin, I notice that this plugin uses non-native obsidian elements (or whatever they're called) which cause these types of problems. Here are some examples :

the filter button and the search bar can't be used on mobile ;
the column menu to change the property type cannot be displayed on small screens ;
the row height changes from theme to theme, even when setting it to normal in the database settings.

Design proposal
With a mix of the two plugins mentioned above, here is the new design proposition :

The database's top bar

The add button is removed and placed in the page header like the kanban plugin, and when pressed a modal would appear, making it easy to use on mobile devices. The use of templates will be migrated to the database settings like this :

use templates (yes/no) ;
choose the template with a file picker.

The open markdown, import, export, open db settings, and manage filter will also be placed either in the page header or the obsidian menu. And don't worry, regarding this issue https://github.com/RafaelGB/obsidian-db-folder/issues/359#issuecomment-1253359668 you can keep the header bar enabled, even if the user hides it in the setting, that's how the kanban plugin does it ;
The enable filter button will be removed and set to always enable filters, and if needed we could add a refresh button to the page header ;
The search will behave just like the kanban plugin ;
The filter groups named buttons will have the same style as the projects plugin tabs
The pagination can be put in as the last row

The main objective behind these changes is to remove as much as possible from the database's top bar to enable mobile support
The column menu
it will be replaced with a custom obsidian menu that can be toggled with either a right click and/or with a custom column button. The menu will have these options :

property type which will create an obsidian modal (works with mobile)
sort ascending
sort descending
remove sort
insert left
insert right
hide
delete
column settings

Recap
My solution may be radical, but in the long term, I think it'll be worth it because of these benefits :

Support for the mobile app without much work ;
Support for most themes without much work ;
The plugin will feel much more native to obsidian ;
Seamless integration with the projects plugin in terms of design.

I know this is a big change, but you don't have to migrate all elements immediately. I'd say the priority is the top bar. Then maybe in the future, I'll open another issue for migrating the table/column to the new design.
If you agree to this proposition and would be willing to receive help, I could send a message to the theme-dev channel in discord, maybe a theme developer would offer to help out with the redesign. This is because DB folder is popular and this will help them in turn not get any unwanted issues in their theme repository.
For which platform do you request this request??
Cross

[ ] Force to show tab title bar
[ ] Move menu actions to bar
[ ] Move filter actions to bar
[ ] Search button/input on bar
[ ] new keyboard action to focus on global search

Move Pagination to bar? to bottom? We will see

Move Pagination to bottom?

Maybe something like this

or this

https://user-images.githubusercontent.com/11924043/204010857-d8abbb63-8e55-46a0-a166-6a380f9f994d.mov
ctrl+F keyboard shortcut working


can't connect to localhost:5000

Don't know if this is a bug or a configuration:
To reproduce:
git clone ...
open vs and then the sln file
In the startup file, change default to connect to local database
public const string DEFAULT_DATABASE_CONNECTIONSTRING = "Data Source=********;Initial Catalog=Conduit;Persist Security Info=True;User ID=conduit;Password=";
and
public const string DEFAULT_DATABASE_PROVIDER = "sqlserver";
start debugging (hitting f5):
In the browser:
Receive 404, also when calling <IP_ADDRESS>:44460: host rejected connection.
In the output it says:
Conduit> Now listening on: http://<IP_ADDRESS>:44460
and later, after calling anything:
Conduit> 14:39:36 [Information] Microsoft.AspNetCore.Hosting.Internal.WebHost Request starting HTTP/1.1 GET http://localhost:56055/api/tags
Conduit> 14:39:36 [Information] Microsoft.AspNetCore.Hosting.Internal.WebHost Request finished in 0.467ms 404
Thanks in advance, I love this project

Ok, I hacked this one like this:
commented the url configuration
used the localhost:pornum/tags (not api/tags as usua)


[go] Use dep instead of glide to reduce the size of vendor

Please see https://github.com/kubeflow/tf-operator/pull/541#issuecomment-381868512

We met the same problem during the development of v1alpha2. And we choose to copy the code from k8s into our code base.
I think maybe we should migrate from glide to dep and use dep prune to remove useless packages.

I think the vendor tool is not the gap since glide and dep are all easy to use. We do not need any additional work in it. Thus I think dep and glide all works for me.
I migrate from glide to dep because we are using some code in k8s.io/kubernetes and k8s code base is too large. We do not expect to put k8s code in our vendor. Now we just copy the code that we used manually into our code, but it is not the right way, I think.
Kubernetes uses godeps because of historical reasons, I think.

Maybe we could use @kubeflow to ask all members for their opinions.

Katib is using dep from the beginning 😊ཽ

There is on-going work to migrate kubernetes/kubernetes to dep as well: https://github.com/kubernetes/kubernetes/pull/57795. I think it is a good idea to standardize dep management across all kubeflow org project.
PS: KVC uses dep.


Fix the bash script mistake

@xUnholy
 Error: Unhandled error: HttpError: Resource not accessible by integration

It's a 403 so you might've forgotten to pay the bill? :D


CONFIG: PAAS-7486 add dependency to network

@k0da we have agreed that we won't do a new build, it will be responsibility of future builder to add all the changes between last release and build

Why? Why? It just a one line addition, and reduced work for next commiter

@k0da changed

Timestamp

@k0da so it is not one line! :) fixed


Requirement Request: Integration: with DataDog / Kibana

Description
We can explore how TiDB Dashboard can be integrated into existing dashboards like DataDog, Kibana.
Category

Feature

Value

Oversea users tend to use DataDog / Kibana to monitor all services. Integrating TiDB Dashboard into their current dashboard is very helpful.

Score: 4

Workload Estimation

15 Person Day

Cancelled for now.


Add CodeClimate and Codacy to automate code quality review and standardize lint

To maintain consistent coding standards, I propose that we hook hedera-sdk-js to CodeClimate and Codacy.
This ensures that we maintain a high code quality standard and focus our energy on code patterns/design and functionality, while offloading mundane code quality checks to standard best practices.

Personally, I disagree. This is already happening through our very extensive eslint configuration. See: https://github.com/launchbadge/eslint-config and https://github.com/hashgraph/hedera-sdk-js/blob/master/.eslintrc.js#L1 and https://github.com/hashgraph/hedera-sdk-js/commit/8df1e37a8347b1baa41e9ee1e5e1bbd3ffb9e5f4/checks?check_suite_id=379299567#step:8:7.
We could stand to clean up some of the lint warnings however. :smile:

Well, linting is a very minor part of what constitutes good code.
Bigger issues usually relate to code duplication, cyclomatic complexity and the like.

@calvinchengx Sorry for not fully explaining that. The term "linting" these days does mean all of that. All codacy does is run eslint with a hyper minimal configuration.

That's why it makes sense to use CodeClimate (as well). Which does a great job with detecting code smells and cyclomatic complexity.
Codacy also does a little more than lint checks.


Resolve unclear license status

Some entries have unclear license status. Resolve the license status one way or the other.

[ ] Aeron
[ ] Eat the Whistle
[ ] Grabble
[ ] Gusanos
[ ] Imperium
[ ] kiki the nanobot
[ ] netrek
[ ] netstatbaseball
[ ] scrolling game engine
[ ] smash battle
[ ] ulstrastar
[ ] yo frankie
[ ] ysoccer

Aeron is under GPL-3.0 (see file AeronEngineMain.cpp). It could be marked better. Maybe contact the author and ask for a readme.

I sent a message to Gabriele Greco, the main programmer of Eat the Whistle, asking for the possibility to add a license notice to the code base.

I sent a message to CMG Lee, the author of Grabble, asking for the license information.

I sent a message to Erik Lindroos, one of the authors of GUSANOS, asking for license information.

I sent a message to Thorsten Kohnhorst, the author of Kiki the nanobot, asking for license information.

I sent a message to Marshall Lake, the author of Netstatsbaseball, asking for license information.

I sent a message to Bert Hekman, one of the authors of Smash Battle, asking for license information.

I sent a message to Corvus, the author of Ultrastar, asking for license information.

I sent a message to Massimo Modica, an active developer of YSoccer, and asked for license information.

Yo frankie is GPL for the code and CC for the artwork according to Libregamewiki, but there is not confirmation in the download package of that.  Need to contact developers.

I found the license information of Yo frankie (https://apricot.blender.org/about-apricot/) saying the artwork content is CC-BY-3.0. But I still would like to convert the SVN to Git and to see if there is more information stored in the SVN.

Marshal Lake, the author of Netstatsbaseball, replied and put the code in the public domain. I will convert the CVS to Git and add Marshal Lakes reply saying it is public domain. :)

Massimo Modica replied and pointed the location of the license info out. It's GPL-2.0.

Thorsten Kohnhorst (kiki the nanobot) replied and confirmed public domain. I will make the conversion of CVS to Git, add a license notice, and tell him about it.

Eric Lindros, an author of Gusanos, replied and confirmed that Gusanos was meant to be GPL2. I will specify it in the code conversion.

I never got an answer from Gabriele Greco, the main programmer of Eat the Whistle, through the Sourceforge message system. However he is (now) also on Github and active and etw is also there and I opened an issue about that there.

I never received a reply from CMG Lee, the author of Grabble, through the Sourceforge message system and I did not find another contact address and did not find the author or the project on Github. I therefore removed it from the database.

Smash battle is now on Github and has license info attached.

I never got a reply from Corvus, the author of Ultrastar, and the website at that time (https://web.archive.org/web/20110727234610/http://www.ultrastargame.com/) as well as the source code do not indicate any license information. ultrastar does not exist on Github or Gitlab. I give up and remove the entry from the database.

Shattered Evil seems to be under GPL.


uag_find_param exits as uag.ual.head is NULL on entry (line 1709)

When entering this routine (from the b2bua module), this immediately exits due to the initial state of le being NULL after being set with the value of uag.ual.head. The SIP addresses are being read correctly from accounts, so I'm guessing this is due to this function (not used anywhere else?).

Are the modules getting initialised before the list of accounts is getting populated? If so how can I delay this?

can you please share your config file ?
keep in mind that modules are loaded in the order that they are listed
in the config file (more or less).
the b2bua module is of type "application":
const struct mod_export DECL_EXPORTS(b2bua) = {
	"b2bua",
	"application",
	module_init,
	module_close
};

.. so it should be loaded with the module_app directive :)
Alfred

Sorry - I only just came across your reply. Yes - I suspect it was something like that. I ended up replicating most of the b2bua code after the accounts module (linking to the library), which seems to work. Please close this issue (though maybe it's worth putting a note somewhere?). Thanks!


Implement dataplane reset

Implement timeouts of packet io, so they close correctly
Add reset to engine and sai API

How will you test this change?

I have task to for an integration test for this to do later


where is the /update-alternatives.sh

i clone the llvm-project as the README' llvm setup step, after the  make and make install, i could not find the /update-alternatives.sh file.

i found the script file in doc, i think it is better to note this file in the gem5-SALAM project, since i try  to find it in llvm-project :)

i found the script file in doc, i think it is better to note this file in the gem5-SALAM project, since i try  to find it in llvm-project :)


Enable importing passwords from Firefox

Auditors: @darkdh
required by https://github.com/brave/browser-laptop/pull/9433

++


adding dash as valid identifier character

Not sure if this is deceptively simple fix, but this allows identifier names to have a dash in them which is supported by handlebars.js.
Spec added to handlebars_spec.rb

Related to #15

I've (finally) been able to try out more your PR and everything seems correct, thanks for your contribution :)


APIKeyModal: Address design inconsistencies

What will this achieve?
adhere to design
How will success be measured?
design sign off
Additional information
The modal should be the "small" size.
Components within a modal should span the full width of the modal, while text only spans 80% of the width. The form field should span the full width.
The info icon should be inline with the bottom text, which should be 16px from the textfield.
There was uncertainty about the link, some of the images in the pattern show without the underline. But it is correct as is!

@davidmenendez saw your name on the epic for this one. feel free to unassign or assign someone else if it's not right!


Use single quotes to avoid shell expansion at time of definition

The $PWD was always translated to my home dir. This PR fixes that issue.

Nice catch, thanks.

Thank you for merging


Add CANable 2.0 support

Since CANable 2.0 is already compatible with socketcan through slcand, this only affects Windows.
The integration could be realized via the libserialport for instance.

This issue is covered in #54


Implement error propagation for null vs non-null fields

fix #173

Can someone please review and/or merge this PR?

bump?

Rebased this PR, but it's failing tests now because it doesn't handle subscriptions correctly.

Updated to handle errors in subscriptions. I'm not sure what the expected behaviour there was, so please take a look at the examples in the tests.

After doing some local testing, I think this PR needs a bit more work to handle nulls in subscriptions correctly. I'm working through the various test cases right now and trying to guess what the expected behaviour us, but any tips on that front would be appreciated.

Updated. I think the tests cover the various edge cases that needed to be handled.

Updated with a more thorough test.

Hi @gracenoah, I have an error propagation branch based off yours, with some additions/changes for handling nullability in lists and non-null fields resolving to null. Should I open a new PR here, or would you like me to open one in your fork so my changes are merged into your branch?

Please open a separate pull request against this repo. Feel free to based it off my branch. I'm unlikely to push hard for this to be merged because we are switching to https://github.com/99designs/gqlgen. It supports the spec a lot better.

Closing this PR as #296 is based on this PR + other changes.

@gracenoah I'd be very curious to know if you have faced any other problems with this library. Especially, cases where this library doesn't support the GraphQL spec...
Any feedback would be highly appreciated. Here or in the Gophers Slack...


Understanding of data availability and its inspection

All need to work on this.
DoD:

Understanding the whole data
Data Info/Description meta data
Data Quality: Usable or not

#4 provided data might not be very useful.
We need to refer:

https://huggingface.co/datasets/McAuley-Lab/Amazon-Reviews-2023
https://nijianmo.github.io/amazon/


added data for UISwitch

Allows RMQ to read and set data property for UISwitch
    switchy = rmq.create(UISwitch).data(true)
    switchy.get.isOn.should == true

SELLLLLLLLLFFFFFF MEEERRRRRRRRRGGGGEEEEEEEE


(doc) Fix usage of status on response timer.

Hi,
I was interested in getting going with Iron and gave your example code a try. I noticed that when I tried to use the Response timer example, I ran into an error with the way status code was imported and then consumed. I've made a change to the README that fixes this issue. Hopefully this will help someone in the future :)

Hi,
looks like you tried to use the examples from the master branch with the released version 0.6. You can find examples for version 0.6 here: https://github.com/iron/iron/tree/0.6-maintenance.


Suggest imports when using an undefined variable

Implements #122
This PR adds suggested imports as quick actions when you use an undefined variable.
Screenshots

It accomplishes this by searching the rojo tree for matching modules then getting relative and absolute paths to the target modules. This feature will prefer to show relative paths over absolute paths, but will use absolute paths when going through a service or through game is necessary.
This PR adds two three settings:

importScriptChildren: Controls whether suggested require paths are allowed to index into scripts. It's common to treat individual scripts as their own resource and all of their children as "private" to that script. When following that convention, you will usually re-export anything you want to be publicly accessible.
With importScriptChildren = false, Roblox LSP will still suggest relative require paths underneath a script that don't index into any new child scripts (as seen in screenshot 1 above).
importIgnore: A set of globs that should never be suggested for automatic import. This is good when using something like Wally which creates many "package links" that the LSP would otherwise see as duplicate module names you could import. This is also shown above in screenshot 2.
importPathType: A choice of which require paths you want the LSP to suggest to you, with choices ranging from only relative paths to only absolute paths and in-between.

Sorry that this is rather large! I found the codebase a bit hard to navigate, so I'm not sure if I've put everything in the best place or if an existing implementations exist for anything I've done. I appreciate any feedback necessary to clean this up and get it merged in!

This is currently just part of the undefined-global diagnostic. I have two thoughts about this:

It would be nice to be able to disable this "suggested imports" feature alone without disabling the diagnostic
I don't actually like using the built-in diagnostics. I prefer to use selene, but I still want to use this "suggested imports" feature.

What do you think is the best route to achieving these goals? (You're more familiar with the codebase and the direction of the project than I am!)

I love it! It remembers me when I was coding in C# and I never imported anything manually.

It would be nice to be able to disable this "suggested imports" feature alone without disabling the diagnostic

I don't think this is necessary since you can decide whether to use it or not.

I don't actually like using the built-in diagnostics. I prefer to use selene, so I usually disable all diagnostics. I still want to use this "suggested imports" feature with diagnostics disabled.

The way this works as a quick fix is perfect since that's how it works in most languages, so it can stay this way, however, there can be an alternative way to do it as a refactor. When implementing it as a refactor, you would have to check if the variable selected is an undefined global, the rest is almost the same.
I have some ideas:

Instead of deciding whether to use relative or absolute paths, you can use both and let the user choose, that is, two quick fixes/refactors.
To be consistent with how services are auto-imported, you should find in the AST a require and then place the import below it.
This could be a quick fix of its own diagnostic instead of undefined-global, this diagnostic will show up on undefined globals that can be auto-imported, this way people will notice it without opening Quick Fix. The diagnostic wouldn't be a warning but a hint or information.

I think importScriptChildren and importIgnore should be in to robloxLsp.misc instead of robloxLsp.diagnostics.

Planning to address feedback here over this coming week. Thank you!

Instead of deciding whether to use relative or absolute paths, you can use both and let the user choose, that is, with multiple quick fixes/refactors.

I originally did this, but I didn't like it because it doubled the available options, and in my case I wouldn't use half of them. Would you be okay if there as an additional setting for this?

Very optional and probably unnecessary, but this could be a quick fix of its own diagnostic instead of undefined-global, this diagnostic will show up on undefined globals that can be auto-imported, this way people will notice it without opening Quick Fix. The diagnostic wouldn't be a warning but a hint or information.

This sounds good, and I almost did this originally. I was worried that showing both undefined-global and some other diagnostic might be weird and unnecessary. This is the best way to get the functionality I'm hoping for with the least work right now though, so I think I'll do it.

Sorry I've been slow on this! I was unexpectedly busy on the week I planned to finish this up, then I went on holiday break and barely even looked at my computer for two weeks. I'm back now and planning to finish this up soon!

I've addressed your feedback and I've done some cleanup by moving import-related functions to their own file.
This should be ready for your next review and potentially merging in!

I think importScriptChildren and importIgnore should be in to robloxLsp.misc instead of robloxLsp.diagnostics.

Done!

Very optional and probably unnecessary, but this could be a quick fix of its own diagnostic instead of undefined-global, this diagnostic will show up on undefined globals that can be auto-imported, this way people will notice it without opening Quick Fix. The diagnostic wouldn't be a warning but a hint or information.

Done!

To be consistent with how services are auto-imported, you should find in the AST a require and then place the import below it.

Done!

Instead of deciding whether to use relative or absolute paths, you can use both and let the user choose, that is, with multiple quick fixes/refactors.

I added a setting for this. I personally don't want to see absolute paths as I don't like the "quick fix" menu being cluttered. Users can choose a setting here that fits their conventions, including one to show both relative and absolute paths.

Should it use robloxLsp.workspace.ignoreDir instead of having its own setting?

I'm not sure. I can think of good reasons for this to go either way. If this is something you're certain you'd like me to change then I'm happy to change it.

I've added a default for the importIgnore setting, as I expect it to be common to ignore the wally index. If you don't ignore it then roblox lsp returns a ton of results that aren't useful.
If you decide it's better to use the workspace.ignoreDir setting:

Just let me know! I have a commit ready.
Let me know if you want me to add the **/__index/** default to ignoreDir or not.

I think it should have its own setting, since most people when using robloxLsp.workspace.ignoreDir ignores the entire packages\vendor folder. Having /__Index/ ignored by default is a good idea and could be by default in robloxLsp.workspace.ignoreDir as well.
I've been testing it for a while and it works fine, but when I import libraries like Roact from ReplicatedStorage, or other modules, I don't like it using the relative path, maybe it should prefer Absolute Paths by default, or there should be a different way to decide where to use Absolute or Relative paths, for example, maybe it could use the shortest one?

I've been testing it for a while and it works fine, but when I import libraries like Roact from ReplicatedStorage, or other modules, I don't like it using the relative path, maybe it should prefer Absolute Paths by default

We can change the default setting here.
An Absolute First option doesn't make sense because there should always be an absolute path, so with Absolute First the relative paths would never show (effectively Absolute Only).
I will be personally making use of Relative First. We all have codebases structured differently, and have different conventions. I'll be using Relative First for a game, but it's also a good setting for developing packages or plugins because both are typically contained in a single folder and should not be requiring from the root game tree.

or there should be a different way to decide where to use Absolute or Relative paths, for example, maybe it could use the shortest one?

I can add an option Shortest First to the importPathType enum for this.
It sounds like for you either Shortest First or Both are best for your codebase and conventions.

One idea I had is another glob that limits what can be required relatively. You could set this to e.g. Packages/** and now Roblox LSP will always use absolute paths for files in that folder.
I think we should:

Implement Shortest First or similar
Potentially implement "always absolute" glob settings
Decide on a good default setting for importPathType
Release this as a first version. Codifying require conventions can be hard, but we have to start somewhere!

Ok then this can be merged!

There were a few changes (discussed above) that I wanted to get in before this was merged. I've set up a small pr here with those changes: https://github.com/NightrainsRbx/RobloxLsp/pull/134


README for pkg/signal, #11585

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "11585" git@github.com:VladimirAus/docker.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

This will update the existing PR, so you do not need to open a new one.


about demo.py

somebody know how to use the demo.py?
what is the command?

python tools/demo.py --config-file your_config_file --input-img your-img-path-or-your-img-dir will be ok.

python tools/demo.py --config-file your-config-file --input-img your-img-path-or-your-img-dir
will be ok

@LikeLy-Journey I found it did not work use your demo. the outputed picture will be fulled with yellow pixels.

@andeyeluguo If you are getting a single class for the entire image you're probably running inference on random weights; make sure you actually loaded a model. The output should print something like load test model from https://github.com/LikeLy-Journey/SegmenTron/blob/e6218e6/segmentron/models/model_zoo.py#L34
You need to download weights from the readme and modify the TEST_MODEL_PATH in the config files if you're using the repo out of the box.


Getting the latest changes

I really need some of the recent fixes. Is there a way I can get them, like 'installing' master instead if a tagged release or something? Also is there an easy way to get a specific fix into my dev environment?

We will soon release v0.14-rc2.

Thanks.

Looks like the source does not get built with that version...
`ERROR in ./modules/DummyApp/client/components/DummyApp.jsx
Module not found: Error: Cannot resolve module 'material-ui/lib/styles/theme-man
ager' in C:\Users\genyd\AppData\Local.meteor\projects\ep2react\modules\DummyApp
\client\components
@ ./modules/DummyApp/client/components/DummyApp.jsx 27:39-86
ERROR in ./modules/DummyApp/client/components/DummyApp.jsx
Module not found: Error: Cannot resolve module 'material-ui/lib/styles/raw-theme
s/dark-raw-theme' in C:\Users\genyd\AppData\Local.meteor\projects\ep2react\modu
les\DummyApp\client\components
@ ./modules/DummyApp/client/components/DummyApp.jsx 31:48-107
ERROR in ./modules/DummyApp/client/components/Header.jsx
Module not found: Error: Cannot resolve module 'material-ui/lib/raised-button' i
n C:\Users\genyd\AppData\Local.meteor\projects\ep2react\modules\DummyApp\client
\components
@ ./modules/DummyApp/client/components/Header.jsx 27:33-73`

seems like webpack cannot resolve material-ui. are you sure it's inside a node_modules folder somewhere?

Yes but there is ni lib folder when installing master

Oh I get it now!
you need to build the src folder.
do the following:

go to root of material-ui folder
do an npm install to install the build tools.
do an npm run build to build the lib folder.

we really need to document this! don't close this issue please.

v0.14.0 was released some time ago. It should be fixed now.


Settings editor should not block on extension host ready

Currently while opening settings editor, it blocks until the extension host is ready.
It should not be blocked, instead listen to configuration changes and update the settings editor.
@bpasero @jrieken  FYI

To verify:
Open Settings editor and reload window.
Make sure all default settings (Core and Built in) are rendered.
Verify by opening User, Workspace, and Folder settings


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>chore(package<EMAIL_ADDRESS>chore(scripts): cover@#overwrite c8 --temp-directory build/coverage ava && c8 report -r lcov --temp-directory build/coverage
chore(engines<EMAIL_ADDRESS>chore(package): add nyc from template
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

.travis.yml

chore(travis): remove node versions 10.14.2
chore(travis): add node versions 10.15.0

Codecov Report

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

@@           Coverage Diff           @@
##           master     #344   +/-   ##
=======================================
  Coverage   95.23%   95.23%
=======================================
  Files           1        1
  Lines          84       84
=======================================
  Hits           80       80
  Misses          4        4

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 659f5c3...3a6abca. Read the comment docs.

Coverage remained the same at 94.0% when pulling 3a6abca5b9fa3ff91d2ec94a69cb92f52fc90da3 on template-sync-1 into 659f5c3db2f31747627b4df5ef77aa5ff1e6b055 on master.


Show matching log

This PR adds the link to the node value.
By clicking on the link, it filters log to matching items.

Made changes.  Please take a look again.

Thank you for the quick response.


translate result is wrong comparing to the google translate website

the class return very wrong translation:
translator.translate("Department of Otolaryngology, Head and Neck Surgery, PLA General Hospital, Beijing", lang_tgt="zh")
'北京广场综肠耳科，头部和颈部手术部 '

But the https://translate.google.com returns correct value 北京解放军总医院耳鼻喉头颈外科

I also spotted this issue. The translations given by the repository are of lower quality than those of the official browser google translate app. Maybe the repository is hitting a google endpoint which is outdated? It is a pity because sometimes the translations are really bad.

Is there any progress on this issue?

Hey Guys, I'm with the same issue here. Some translations from English to Polish for example and the API returns basically a translation without context or not based in expressions.
I'm not really into sweets! = Polish: Nie jestem naprawdę słodycze!
On google translator website = nie przepadam za słodyczami
I was thinking that was the option of use the Pronounce, but it is not.

I found an explanation on StackOverflow. Basically, the website has a google auto-correct service, which provides a suggested input to the translation app rather than your input.


Error format consistency

I have came across at least two different formats indicating errors:

"status" : "error"
"success" : "false"

Then the errors are given in at least two ways:

"errors" object with "full_errors", etc
"errors" : ["error", "messages"]

Then sometimes the success payload has "status" : "success", sometimes "success" : "true" and sometimes nothing at all.
Is there a specific reason for this, as it is rather inconvenient to handle all this cases client side?

i'm all in favor of standardizing these errors in a way that they can still be mapped back to input fields and can account for localization. let me know if you're interested in putting together a PR @MoridinBG .
As a side note, I also noticed that validation attempts that fail always are given the "Invalid Credentials" message. Think this should just passthrough whatever server error message is provided, since it is also breaking localization.

cc @mattblang


Broken link to live demo in Getting started docs

The link in Play with a live demo in Getting started to https://fivethirtyeight.datasettes.com/fivethirtyeight is broken and the datasette is no longer working (maybe due to the end of the free tier).

It's working again now - not sure what happened there, I was paying for Heroku for that already.


Not offered tooltip has the wrong academic year

Compare to the tooltip in the course catalog:

oh lol we hardcode it https://github.com/sipb/hydrant/blob/a07ebcd99427cfd9356d83092cd8932313757f60/src/components/ActivityDescription.tsx#L63

(the fix is to probably use state.term to get the academic year)


RFP - SMTube

Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details
Software project URL :
http://www.smtube.org/
Direct download URL for the software / installer :
http://sourceforge.net/projects/smtube/files/SMTube/18.11.0/smtube-18.11.0-x64.exe
http://sourceforge.net/projects/smtube/files/SMTube/18.11.0/smtube-18.11.0-win32.exe
Software summary / short description:
Useful FOSS add-on for SMPlayer (which already has a chocolatey package) -- YouTube Browser
Package Expectations
Has 32bit and 64 versions

Status: Review
https://chocolatey.org/packages/smtube

Status: Published

https://chocolatey.org/packages/smtube

Can be closed.


Make pylint check for Google style imports

We can use the package pylint-google-style-guide-imports-enforcing to make pylint check the import style, as we want to follow that style but we hardly do because there is no enforcement.

Soft-blocked on:

https://github.com/frequenz-floss/frequenz-repo-config-python/discussions/56

It would be good to see how this check works and how code that passes this check looks like as part of the conversation.


colorblocks() function is commented out

On the current version of day-planner set for release on github the colorblocks() function is commented out, which prevents the site from working as intended and throws multiple errors. Pretty minor but it stops the site from working when it's cloned from the repository. The script still makes calls to the function on line 136 and 217 which prevented the site from working on chrome.

go for it

star the repo


Node Compile Error - Do not use v-for index as key on  children, this is the same as not using keys.

`ERROR in ./node_modules/vue-loader/lib/template-compiler?{"id":"data-v-40d2a988","hasScoped":true,"buble":{"transforms":{}}}!./node_modules/vue-loader/lib/selector.js?type=template&index=0!./node_modules/vue-flash/src/Flash.vue
(Emitted value instead of an instance of Error)
Error compiling template:

Do not use v-for index as key on  children, this is the same as not using keys.

@ ./node_modules/vue-flash/src/Flash.vue 10:23-222
@ ./resources/assets/js/app.js
@ multi ./resources/assets/js/app.js ./resources/assets/less/app.less ./resources/assets/rebrand-styles/less/index.less`
The weird quick fix is to add +0 to the index for the v-for. I'm sure there's a more elegant way of fixing this.

Resolved in #22


Technical coupling of user management in th FC Hub

Several independent tools are integrated in the FC Hub, most prominently: EOX and rasdaman.
Q: How to establish a uniform handling of [some agreed policy] (https://github.com/FAIRiCUBE/FAIRiCUBE-Hub-issue-tracker/issues/34) from a user and administrator perspective?

I imagine we need a Web page that allows an admin to manage FC users, which internally sends requests to both EOX and rasdaman? In rasdaman we have HTTP API that allow user/privilege management, it should be straightforward to use that.

Could both technical partners please provide details of user management systems available from your platforms. Then we can better identify a common way forward.

fine with us; where should we document it?

I'd have expected such info under D4.1 but it never materialized.
As user management mostly pertains to data access, how about setting up a page under data requests?

ok, thanks for the guidance. Will start on the main page now, we can move that to a wiki page once the wiki is public again.


problem of building test

There is following error when I build the test:
[ 39%] Linking C executable ../bin/hg_test_read_bw
/usr/bin/ld: ../bin/libmercury.a(mercury.c.o):(.data+0x0): multiple definition of hg_log_mask'; ../bin/libmercury_hl.a(mercury_hl.c.o):(.data+0x0): first defined here /usr/bin/ld: ../bin/libna.a(na.c.o):(.data+0x0): multiple definition of na_log_mask'; ../bin/libna_test.a(na_test.c.o):(.data+0x0): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [Testing/CMakeFiles/hg_test_read_bw.dir/build.make:93: bin/hg_test_read_bw] Error 1
make[1]: *** [CMakeFiles/Makefile2:1259: Testing/CMakeFiles/hg_test_read_bw.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
The gcc version is 8.3.0 and the git commit is c2c262813811c3ede2 (master branch)
Thanks!

@wangzhezhe is this resolved with current master branch or do you still see that issue?

@soumagne Thanks for your help, I could try it


Fix linker warning on windows related to import/export of dll symbols

PR #502 revamped our dll import/export process on Windows.
I thought I fixed all the linker warnings, but it appears that we still have some of the form:

LINK : warning LNK4217: symbol '?checksAreErrors@debug@slic@axom@@2_NA (public: static bool axom::slic::debug::checksAreErrors)' defined in 'slic.obj' is imported by 'mint_mesh_curvilinear_mesh.obj' in function '"public: class axom::sidre::View * __cdecl axom::sidre::View::setString(class std::basic_string<char,struct std::char_traits,class std::allocator > const &)" (?setString@View@sidre@axom@@QEAAPEAV123@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)' [D:\a\axom\axom\build-axom\axom\mint\tests\mint_mesh_curvilinear_mesh_test.vcxproj]

I think the problem is related to our usage of object libraries: We want to export some symbols (e.g. slic::debug::checksAreErrors to other libraries, but it is also used by other components within the Axom library (which should not view these as external).
One possible resolution could be to add flags to the axom libraries (but not to axom's users) to disable this warning.

In #570, I tried to resolve this by linking the mint tests against all of axom instead of just mint.
Unfortunately, this made the issue worse: It went from seemingly harmless linker warnings to a (separate) linker error
(see: https://github.com/LLNL/axom/actions/runs/873181925)
In a second attempt, I made the mint tests depend on slic in addition to mint, which did not resolve the original problem
(see: https://github.com/LLNL/axom/actions/runs/873256911 )


⚠ Adacta-fintech.com has degraded performance

In 66d71c3, Adacta-fintech.com (https://www.adacta-fintech.com) experienced degraded performance:

HTTP code: 200
Response time: 2018 ms

Resolved: Adacta-fintech.com performance has improved in 8366850 after 7 minutes.


Get test_sleep_star.py working under new configuration scheme

After #396 is merged, we'll need to rewrite some of the tests we had to work under the new configuration system.
One of these tests is called "tests_broken/test_sleep_star.py". It consists of training the LocationEncoder on simulated images of stars under two different settings. TestSleepStarTiles runs on a "vanilla" generated image, while TestSleepStarOneTile runs on an image that consists of just one tile (to check that we handle that edge case).
The steps to get this working on the new configuration system are:

Make a folder called tests/star_basic.
Look at each test and its overrides. These tell you what settings are needed to recreate the new test.
https://github.com/prob-ml/bliss/blob/4b3d08202ee393d2909e2cd445fafd5dfd8b88a2/tests_broken/test_sleep_star.py#L6-L12
https://github.com/prob-ml/bliss/blob/4b3d08202ee393d2909e2cd445fafd5dfd8b88a2/tests_broken/test_sleep_star.py#L35-L40
Reference the old configuration: https://github.com/prob-ml/bliss/tree/f6f92fb36bebb919525454f6da66bab3c9b761f3/config to create a new configuration file tests/star_basic/star_basic.yaml. See tests/m2/m2.yaml for a template. You mostly just need to update the settings for the dataset, encoder, prior, and decoder.
Write a conftest.py which creates a pytest fixture that loads this configuration (see tests/m2/conftest.yaml) for an example.
Copy tests_broken/test_sleep_star.py over to tests/star_basic and rewrite it to work with the new documentation.
Run pytest -k sleep_star tests to check that it works
Run pytest -k sleep_star tests --gpu to check that it works on the GPU (and the model trains to reasonable accuracy).

I thought this would be a good first issue at first, but it requires getting up to speed with a lot all at once... I can write a PR which gets part of this done.

Closed by #483


Fixes mispelled typesetPromise method.

Replaces TypesetPromise by typesetPromise in two places:

Fixes the spelling in the lab.
Fixes spelling in startup.ts, although I could not produce an error with the old cap spelling.

Thanks for catching these.