CrashLoopBackOff / Error on Raspberry Pi 4

This issue is used to track the CrashLoopBackOff error on Raspberry Pi 4 instead of Cent OS
Environmental Info:
K3s Version:

k3s version v1.21.1+k3s1 (75dba57f)
go version go1.16.4

Node(s) CPU architecture, OS, and Version:

Linux kmaster 5.10.17-v7l+ #1421 SMP Thu May 27 14:00:13 BST 2021 armv7l GNU/Linux

Cluster Configuration:

1 server, 1 agent (both are Raspberry pi 4)
Describe the bug:

Opening another issue as suggested https://github.com/k3s-io/k3s/issues/1019#issuecomment-800541872 to keep track of the pod CrashLoopBackOff
:~ $ kubectl get pods -A
NAMESPACE     NAME                                      READY   STATUS             RESTARTS   AGE
kube-system   helm-install-traefik-crd-krv7p            0/1     Completed          0          26m
kube-system   helm-install-traefik-vn7wv                0/1     Completed          2          26m
kube-system   svclb-traefik-wrrkh                       2/2     Running            2          25m
kube-system   traefik-97b44b794-gwkss                   1/1     Running            1          25m
kube-system   svclb-traefik-q8qhq                       2/2     Running            0          15m
kube-system   coredns-7448499f4d-f7kjn                  0/1     CrashLoopBackOff   5          26m
kube-system   metrics-server-86cbb8457f-b7dnm           0/1     CrashLoopBackOff   5          26m
kube-system   local-path-provisioner-5ff76fc89d-q5tpr   0/1     Error              6          26m

Steps To Reproduce:

After making sure both master node and worker node are ready reboot both raspberry pi
After rebooting,

:~ $ kubectl get nodes
NAME      STATUS     ROLES                  AGE   VERSION
knode0    NotReady   <none>                 15m   v1.21.1+k3s1
kmaster   Ready      control-plane,master   26m   v1.21.1+k3s1

Expected behavior:
Expected both nodes to be ready
Actual behavior:
worker node was never ready
Additional context / logs:
If I execute the kill-all script and reboot the server with k3s server start it starts working again, but this is inconvenient.

Just seeing that they're crashlooping doesn't give us much to work with. Can you provide kubectl logs and kubectl describe pod output from those two pods?

After rebooting, was able to reproduce again
NAMESPACE     NAME                                      READY   STATUS             RESTARTS   AGE
kube-system   helm-install-traefik-crd-krv7p            0/1     Completed          0          102m
kube-system   helm-install-traefik-vn7wv                0/1     Completed          2          102m
kube-system   svclb-traefik-wrrkh                       2/2     Running            10         100m
kube-system   traefik-97b44b794-gwkss                   1/1     Running            6          100m
kube-system   svclb-traefik-q8qhq                       2/2     Running            2          91m
kube-system   metrics-server-86cbb8457f-b7dnm           0/1     CrashLoopBackOff   16         102m
kube-system   local-path-provisioner-5ff76fc89d-q5tpr   0/1     CrashLoopBackOff   18         102m
kube-system   coredns-7448499f4d-f7kjn                  0/1     CrashLoopBackOff   18         102m

For metrics-server-86cbb8457f-b7dnm
lau@debian:~ $ kubectl logs -n kube-system metrics-server-86cbb8457f-b7dnm
I0602 17:58:04.650011       1 serving.go:312] Generated self-signed cert (apiserver.local.config/certificates/apiserver.crt, apiserver.local.config/certificates/apiserver.key)
Error: Get https://<IP_ADDRESS>:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication: dial tcp <IP_ADDRESS>:443: connect: connection refused
Usage:
   [flags]

Flags:
      --alsologtostderr                                         log to standard error as well as files
      --authentication-kubeconfig string                        kubeconfig file pointing at the 'core' kubernetes server with enough rights to create tokenaccessreviews.authentication.k8s.io.
      --authentication-skip-lookup                              If false, the authentication-kubeconfig will be used to lookup missing authentication configuration from the cluster.
      --authentication-token-webhook-cache-ttl duration         The duration to cache responses from the webhook token authenticator. (default 10s)
      --authentication-tolerate-lookup-failure                  If true, failures to look up missing authentication configuration from the cluster are not considered fatal. Note that this can result in authentication that treats all requests as anonymous.
      --authorization-always-allow-paths strings                A list of HTTP paths to skip during authorization, i.e. these are authorized without contacting the 'core' kubernetes server.
      --authorization-kubeconfig string                         kubeconfig file pointing at the 'core' kubernetes server with enough rights to create subjectaccessreviews.authorization.k8s.io.
      --authorization-webhook-cache-authorized-ttl duration     The duration to cache 'authorized' responses from the webhook authorizer. (default 10s)
      --authorization-webhook-cache-unauthorized-ttl duration   The duration to cache 'unauthorized' responses from the webhook authorizer. (default 10s)
      --bind-address ip                                         The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank, all interfaces will be used (<IP_ADDRESS> for all IPv4 interfaces and :: for all IPv6 interfaces). (default <IP_ADDRESS>)
      --cert-dir string                                         The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "apiserver.local.config/certificates")
      --client-ca-file string                                   If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
      --contention-profiling                                    Enable lock contention profiling, if profiling is enabled
  -h, --help                                                    help for this command
      --http2-max-streams-per-connection int                    The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default.
      --kubeconfig string                                       The path to the kubeconfig used to connect to the Kubernetes API server and the Kubelets (defaults to in-cluster config)
      --kubelet-certificate-authority string                    Path to the CA to use to validate the Kubelet's serving certificates.
      --kubelet-insecure-tls                                    Do not verify CA of serving certificates presented by Kubelets.  For testing purposes only.
      --kubelet-port int                                        The port to use to connect to Kubelets. (default 10250)
      --kubelet-preferred-address-types strings                 The priority of node address types to use when determining which address to use to connect to a particular node (default [Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP])
      --log-flush-frequency duration                            Maximum number of seconds between log flushes (default 5s)
      --log_backtrace_at traceLocation                          when logging hits line file:N, emit a stack trace (default :0)
      --log_dir string                                          If non-empty, write log files in this directory
      --log_file string                                         If non-empty, use this log file
      --logtostderr                                             log to standard error instead of files (default true)
      --metric-resolution duration                              The resolution at which metrics-server will retain metrics. (default 1m0s)
      --profiling                                               Enable profiling via web interface host:port/debug/pprof/ (default true)
      --requestheader-allowed-names strings                     List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed.
      --requestheader-client-ca-file string                     Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests.
      --requestheader-extra-headers-prefix strings              List of request header prefixes to inspect. X-Remote-Extra- is suggested. (default [x-remote-extra-])
      --requestheader-group-headers strings                     List of request headers to inspect for groups. X-Remote-Group is suggested. (default [x-remote-group])
      --requestheader-username-headers strings                  List of request headers to inspect for usernames. X-Remote-User is common. (default [x-remote-user])
      --secure-port int                                         The port on which to serve HTTPS with authentication and authorization.If 0, don't serve HTTPS at all. (default 443)
      --skip_headers                                            If true, avoid header prefixes in the log messages
      --stderrthreshold severity                                logs at or above this threshold go to stderr
      --tls-cert-file string                                    File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir.
      --tls-cipher-suites strings                               Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be use.  Possible values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_RC4_128_SHA
      --tls-min-version string                                  Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12
      --tls-private-key-file string                             File containing the default x509 private key matching --tls-cert-file.
      --tls-sni-cert-key namedCertKey                           A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default [])
  -v, --v Level                                                 number for the log level verbosity
      --vmodule moduleSpec                                      comma-separated list of pattern=N settings for file-filtered logging

panic: Get https://<IP_ADDRESS>:443/api/v1/namespaces/kube-system/configmaps/extension-apiserver-authentication: dial tcp <IP_ADDRESS>:443: connect: connection refused

goroutine 1 [running]:
main.main()
	/go/src/github.com/kubernetes-incubator/metrics-server/cmd/metrics-server/metrics-server.go:39 +0x10c

lau@debian:~ $ kubectl describe -n kube-system pods metrics-server-86cbb8457f-b7dnm
Name:                 metrics-server-86cbb8457f-b7dnm
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Node:                 kmaster/<IP_ADDRESS>
Start Time:           Wed, 02 Jun 2021 12:14:05 -0400
Labels:               k8s-app=metrics-server
                      pod-template-hash=86cbb8457f
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/metrics-server-86cbb8457f
Containers:
  metrics-server:
    Container ID:   containerd://6b4aca354e1be2fef0e607ddbdc1d53f3fddabe4fe9e12889fd66796cbefb963
    Image:          rancher/metrics-server:v0.3.6
    Image ID:       docker.io/rancher/metrics-server@sha256:b85628b103169d7db52a32a48b46d8942accb7bde3709c0a4888a23d035f9f1e
    Port:           <none>
    Host Port:      <none>
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
      Started:      Wed, 02 Jun 2021 13:57:57 -0400
      Finished:     Wed, 02 Jun 2021 13:58:10 -0400
    Ready:          False
    Restart Count:  18
    Environment:    <none>
    Mounts:
      /tmp from tmp-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-w27w2 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  tmp-dir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  kube-api-access-w27w2:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node-role.kubernetes.io/control-plane:NoSchedule op=Exists
                             node-role.kubernetes.io/master:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age                    From               Message
  ----     ------                  ----                   ----               -------
  Normal   Scheduled               105m                   default-scheduler  Successfully assigned kube-system/metrics-server-86cbb8457f-b7dnm to kmaster
  Normal   Pulling                 105m                   kubelet            Pulling image "rancher/metrics-server:v0.3.6"
  Normal   Pulled                  104m                   kubelet            Successfully pulled image "rancher/metrics-server:v0.3.6" in 20.181006925s
  Normal   Created                 104m                   kubelet            Created container metrics-server
  Normal   Started                 104m                   kubelet            Started container metrics-server
  Normal   SandboxChanged          84m                    kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  82m (x4 over 84m)      kubelet            Container image "rancher/metrics-server:v0.3.6" already present on machine
  Normal   Created                 82m (x4 over 84m)      kubelet            Created container metrics-server
  Normal   Started                 82m (x4 over 84m)      kubelet            Started container metrics-server
  Warning  BackOff                 79m (x20 over 84m)     kubelet            Back-off restarting failed container
  Warning  FailedMount             77m                    kubelet            MountVolume.SetUp failed for volume "kube-api-access-w27w2" : [failed to fetch token: serviceaccounts "metrics-server" is forbidden: User "system:node:kmaster" cannot create resource "serviceaccounts/token" in API group "" in the namespace "kube-system": no relationship found between node 'kmaster' and this object, failed to sync configmap cache: timed out waiting for the condition]
  Warning  FailedCreatePodSandBox  77m                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "9131bc6ba17249ed7611ced6bcd8ee5cb3115f4e6d7e2788fd2a4e70f4cc16eb": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  77m                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "568e3c8fa55ea1af77488c9e09c74cf690299250612dc2d012a6dc760ba011f1": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          75m (x3 over 77m)      kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  72m (x4 over 74m)      kubelet            Container image "rancher/metrics-server:v0.3.6" already present on machine
  Normal   Created                 72m (x4 over 74m)      kubelet            Created container metrics-server
  Normal   Started                 72m (x4 over 74m)      kubelet            Started container metrics-server
  Warning  BackOff                 70m (x18 over 74m)     kubelet            Back-off restarting failed container
  Warning  FailedMount             68m                    kubelet            MountVolume.SetUp failed for volume "kube-api-access-w27w2" : failed to fetch token: serviceaccounts "metrics-server" is forbidden: User "system:node:kmaster" cannot create resource "serviceaccounts/token" in API group "" in the namespace "kube-system": no relationship found between node 'kmaster' and this object
  Normal   SandboxChanged          68m                    kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  68m                    kubelet            Container image "rancher/metrics-server:v0.3.6" already present on machine
  Normal   Created                 68m                    kubelet            Created container metrics-server
  Normal   Started                 68m                    kubelet            Started container metrics-server
  Warning  FailedCreatePodSandBox  11m                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "e8ea00cdd92b4994e795eb9e6a3d2e4a12798f40c3124014c9696e54c1013df9": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  11m                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "a9ace9c7e119e6c7c9ffcbe2d94ca533d11304cccc17d9916cb771052573dd58": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          10m (x3 over 11m)      kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  10m                    kubelet            Container image "rancher/metrics-server:v0.3.6" already present on machine
  Normal   Created                 10m                    kubelet            Created container metrics-server
  Normal   Started                 10m                    kubelet            Started container metrics-server
  Warning  BackOff                 10m                    kubelet            Back-off restarting failed container
  Warning  FailedCreatePodSandBox  10m                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "81757c458230e3be4b84bc643cb345109f21b49d1bdb752e00475c9b0daa0f67": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  10m                    kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "0f5ad8cef733b2c01b72db4f7a89f48fc06db19c316ae06d4bc06243f4c961fb": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          7m43s (x3 over 10m)    kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   SandboxChanged          4m59s                  kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  2m54s (x4 over 4m57s)  kubelet            Container image "rancher/metrics-server:v0.3.6" already present on machine
  Normal   Created                 2m54s (x4 over 4m56s)  kubelet            Created container metrics-server
  Normal   Started                 2m54s (x4 over 4m56s)  kubelet            Started container metrics-server
  Warning  BackOff                 88s (x12 over 4m44s)   kubelet            Back-off restarting failed container

For local-path-provisioner-5ff76fc89d-q5tpr
lau@debian:~ $ kubectl logs -n kube-system local-path-provisioner-5ff76fc89d-q5tpr
time="2021-06-02T18:00:05Z" level=fatal msg="Error starting daemon: Cannot start Provisioner: failed to get Kubernetes server version: Get https://<IP_ADDRESS>:443/version?timeout=32s: dial tcp <IP_ADDRESS>:443: connect: connection refused"

Name:                 local-path-provisioner-5ff76fc89d-q5tpr
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-node-critical
Node:                 kmaster/<IP_ADDRESS>
Start Time:           Wed, 02 Jun 2021 12:14:05 -0400
Labels:               app=local-path-provisioner
                      pod-template-hash=5ff76fc89d
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/local-path-provisioner-5ff76fc89d
Containers:
  local-path-provisioner:
    Container ID:  containerd://7319d0a1c3834f8b2dca72d7d9ac58783aa8a34ccfc39c82fc20bac274303636
    Image:         rancher/local-path-provisioner:v0.0.19
    Image ID:      docker.io/rancher/local-path-provisioner@sha256:9666b1635fec95d4e2251661e135c90678b8f45fd0f8324c55db99c80e2a958c
    Port:          <none>
    Host Port:     <none>
    Command:
      local-path-provisioner
      start
      --config
      /etc/config/config.json
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 02 Jun 2021 14:00:05 -0400
      Finished:     Wed, 02 Jun 2021 14:00:05 -0400
    Ready:          False
    Restart Count:  20
    Environment:
      POD_NAMESPACE:  kube-system (v1:metadata.namespace)
    Mounts:
      /etc/config/ from config-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-xrsg4 (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      local-path-config
    Optional:  false
  kube-api-access-xrsg4:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 CriticalAddonsOnly op=Exists
                             node-role.kubernetes.io/control-plane:NoSchedule op=Exists
                             node-role.kubernetes.io/master:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age                     From               Message
  ----     ------                  ----                    ----               -------
  Normal   Scheduled               107m                    default-scheduler  Successfully assigned kube-system/local-path-provisioner-5ff76fc89d-q5tpr to kmaster
  Normal   Pulling                 107m                    kubelet            Pulling image "rancher/local-path-provisioner:v0.0.19"
  Normal   Pulled                  107m                    kubelet            Successfully pulled image "rancher/local-path-provisioner:v0.0.19" in 14.544771079s
  Normal   Created                 107m                    kubelet            Created container local-path-provisioner
  Normal   Started                 107m                    kubelet            Started container local-path-provisioner
  Normal   SandboxChanged          87m                     kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  86m (x4 over 87m)       kubelet            Container image "rancher/local-path-provisioner:v0.0.19" already present on machine
  Normal   Created                 86m (x4 over 87m)       kubelet            Created container local-path-provisioner
  Normal   Started                 86m (x4 over 87m)       kubelet            Started container local-path-provisioner
  Warning  BackOff                 82m (x25 over 87m)      kubelet            Back-off restarting failed container
  Warning  FailedMount             80m                     kubelet            MountVolume.SetUp failed for volume "config-volume" : failed to sync configmap cache: timed out waiting for the condition
  Warning  FailedMount             80m                     kubelet            MountVolume.SetUp failed for volume "kube-api-access-xrsg4" : [failed to fetch token: serviceaccounts "local-path-provisioner-service-account" is forbidden: User "system:node:kmaster" cannot create resource "serviceaccounts/token" in API group "" in the namespace "kube-system": no relationship found between node 'kmaster' and this object, failed to sync configmap cache: timed out waiting for the condition]
  Warning  FailedCreatePodSandBox  80m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "f29b3fb130131508ffd544d3a2c4ef56b31098ec0a38103d0d5364fcc8000824": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  80m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "f8b02f2a65e73de8e888eee4669a6a25017d25c06ce703c4110ecfcc9951e34e": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          77m (x3 over 80m)       kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Started                 76m (x3 over 77m)       kubelet            Started container local-path-provisioner
  Normal   Pulled                  76m (x4 over 77m)       kubelet            Container image "rancher/local-path-provisioner:v0.0.19" already present on machine
  Normal   Created                 76m (x4 over 77m)       kubelet            Created container local-path-provisioner
  Warning  BackOff                 72m (x22 over 77m)      kubelet            Back-off restarting failed container
  Warning  FailedMount             71m                     kubelet            MountVolume.SetUp failed for volume "kube-api-access-xrsg4" : failed to fetch token: serviceaccounts "local-path-provisioner-service-account" is forbidden: User "system:node:kmaster" cannot create resource "serviceaccounts/token" in API group "" in the namespace "kube-system": no relationship found between node 'kmaster' and this object
  Normal   SandboxChanged          71m                     kubelet            Pod sandbox changed, it will be killed and re-created.
  Warning  BackOff                 70m                     kubelet            Back-off restarting failed container
  Normal   Pulled                  70m (x2 over 71m)       kubelet            Container image "rancher/local-path-provisioner:v0.0.19" already present on machine
  Normal   Created                 70m (x2 over 71m)       kubelet            Created container local-path-provisioner
  Normal   Started                 70m (x2 over 71m)       kubelet            Started container local-path-provisioner
  Warning  FailedCreatePodSandBox  14m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "b344ef4137b02fbe78e6aad2105a2e0b14495ff173730ae59afe7c8154d54f30": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          13m (x2 over 14m)       kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  13m                     kubelet            Container image "rancher/local-path-provisioner:v0.0.19" already present on machine
  Normal   Created                 13m                     kubelet            Created container local-path-provisioner
  Normal   Started                 13m                     kubelet            Started container local-path-provisioner
  Warning  BackOff                 13m (x2 over 13m)       kubelet            Back-off restarting failed container
  Warning  FailedCreatePodSandBox  12m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "d5f733db6e7fd368e251e69187d270adaeaf30b1fc620f16794c1e95ee8e84e0": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          12m (x2 over 12m)       kubelet            Pod sandbox changed, it will be killed and re-created.
  Warning  FailedCreatePodSandBox  12m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "ae4a5d1471357c391e44aa6782212167ca6f37ae7161fb1873997a472c799ffb": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          7m45s                   kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  6m9s (x4 over 7m43s)    kubelet            Container image "rancher/local-path-provisioner:v0.0.19" already present on machine
  Normal   Created                 6m9s (x4 over 7m42s)    kubelet            Created container local-path-provisioner
  Normal   Started                 6m9s (x4 over 7m42s)    kubelet            Started container local-path-provisioner
  Warning  BackOff                 2m44s (x25 over 7m39s)  kubelet            Back-off restarting failed container

For coredns-7448499f4d-f7kjn
lau@debian:~ $ kubectl logs -n kube-system coredns-7448499f4d-f7kjn
plugin/kubernetes: Get "https://<IP_ADDRESS>:443/version?timeout=32s": dial tcp <IP_ADDRESS>:443: connect: connection refused

lau@debian:~ $ kubectl describe  -n kube-system pod coredns-7448499f4d-f7kjn
Name:                 coredns-7448499f4d-f7kjn
Namespace:            kube-system
Priority:<PHONE_NUMBER>
Priority Class Name:  system-cluster-critical
Node:                 kmaster/<IP_ADDRESS>
Start Time:           Wed, 02 Jun 2021 12:14:05 -0400
Labels:               k8s-app=kube-dns
                      pod-template-hash=7448499f4d
Annotations:          <none>
Status:               Running
IP:                   <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/coredns-7448499f4d
Containers:
  coredns:
    Container ID:  containerd://2003e2cd3a50aafd845bca6d53c2784bf78354cb639f48c8673cc12730ac0844
    Image:         rancher/coredns-coredns:1.8.3
    Image ID:      docker.io/rancher/coredns-coredns@sha256:cd0f6ef34a9ee6145c0bcbc0a4511a04f81dc2c91582140f0f0250be834b5f27
    Ports:         53/UDP, 53/TCP, 9153/TCP
    Host Ports:    0/UDP, 0/TCP, 0/TCP
    Args:
      -conf
      /etc/coredns/Corefile
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 02 Jun 2021 14:00:11 -0400
      Finished:     Wed, 02 Jun 2021 14:00:11 -0400
    Ready:          False
    Restart Count:  20
    Limits:
      memory:  170Mi
    Requests:
      cpu:        100m
      memory:     70Mi
    Liveness:     http-get http://:8080/health delay=60s timeout=1s period=10s #success=1 #failure=3
    Readiness:    http-get http://:8181/ready delay=0s timeout=1s period=2s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /etc/coredns from config-volume (ro)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-xjrzn (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      coredns
    Optional:  false
  kube-api-access-xjrzn:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              beta.kubernetes.io/os=linux
Tolerations:                 CriticalAddonsOnly op=Exists
                             node-role.kubernetes.io/control-plane:NoSchedule op=Exists
                             node-role.kubernetes.io/master:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age                     From               Message
  ----     ------                  ----                    ----               -------
  Normal   Scheduled               109m                    default-scheduler  Successfully assigned kube-system/coredns-7448499f4d-f7kjn to kmaster
  Normal   Pulling                 109m                    kubelet            Pulling image "rancher/coredns-coredns:1.8.3"
  Normal   Pulled                  109m                    kubelet            Successfully pulled image "rancher/coredns-coredns:1.8.3" in 20.229897523s
  Normal   Created                 108m                    kubelet            Created container coredns
  Normal   Started                 108m                    kubelet            Started container coredns
  Warning  DNSConfigForming        92m (x18 over 109m)     kubelet            Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: <IP_ADDRESS> <IP_ADDRESS> 2001:558:feed::1
  Normal   SandboxChanged          89m                     kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Created                 88m (x2 over 89m)       kubelet            Created container coredns
  Normal   Pulled                  88m (x2 over 89m)       kubelet            Container image "rancher/coredns-coredns:1.8.3" already present on machine
  Normal   Started                 88m (x2 over 89m)       kubelet            Started container coredns
  Warning  BackOff                 88m (x7 over 88m)       kubelet            Back-off restarting failed container
  Warning  DNSConfigForming        84m (x39 over 89m)      kubelet            Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: <IP_ADDRESS> <IP_ADDRESS> 2001:558:feed::1
  Warning  FailedMount             81m                     kubelet            MountVolume.SetUp failed for volume "config-volume" : failed to sync configmap cache: timed out waiting for the condition
  Warning  FailedMount             81m                     kubelet            MountVolume.SetUp failed for volume "kube-api-access-xjrzn" : [failed to fetch token: serviceaccounts "coredns" is forbidden: User "system:node:kmaster" cannot create resource "serviceaccounts/token" in API group "" in the namespace "kube-system": no relationship found between node 'kmaster' and this object, failed to sync configmap cache: timed out waiting for the condition]
  Warning  FailedCreatePodSandBox  81m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "b8990d62872cf3315d34dcafafb42d96c053453c8bef8987724ea5c360797836": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  81m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "9f5920a4993e5d1d6e47c92696d2404ed6f2c648c39e320ea5ef853fde57d528": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          81m (x3 over 81m)       kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  79m                     kubelet            Container image "rancher/coredns-coredns:1.8.3" already present on machine
  Normal   Created                 79m                     kubelet            Created container coredns
  Normal   Started                 79m                     kubelet            Started container coredns
  Warning  Unhealthy               79m (x5 over 79m)       kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:8181/ready": dial tcp <IP_ADDRESS>:8181: connect: connection refused
  Warning  BackOff                 79m                     kubelet            Back-off restarting failed container
  Warning  DNSConfigForming        74m (x40 over 81m)      kubelet            Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: <IP_ADDRESS> <IP_ADDRESS> 2001:558:feed::1
  Warning  FailedMount             72m                     kubelet            MountVolume.SetUp failed for volume "kube-api-access-xjrzn" : failed to fetch token: serviceaccounts "coredns" is forbidden: User "system:node:kmaster" cannot create resource "serviceaccounts/token" in API group "" in the namespace "kube-system": no relationship found between node 'kmaster' and this object
  Warning  FailedMount             72m                     kubelet            MountVolume.SetUp failed for volume "config-volume" : failed to sync configmap cache: timed out waiting for the condition
  Normal   SandboxChanged          72m                     kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  72m                     kubelet            Container image "rancher/coredns-coredns:1.8.3" already present on machine
  Normal   Created                 72m                     kubelet            Created container coredns
  Normal   Started                 72m                     kubelet            Started container coredns
  Warning  Unhealthy               72m (x15 over 72m)      kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:8181/ready": dial tcp <IP_ADDRESS>:8181: connect: connection refused
  Warning  DNSConfigForming        17m (x49 over 72m)      kubelet            Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: <IP_ADDRESS> <IP_ADDRESS> 2001:558:feed::1
  Warning  FailedCreatePodSandBox  15m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "b825e249d58e759b1d5001994196bc02d641aa051a5b11005753e462d24b8c9b": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  15m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "faf7f833f7c69b7a900e568b5cd67811814e9b5629d6b7e9d768ca878189fb9b": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  15m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "f6d2f05091d34723758aad0e875ea2c43a1f783b63d38f313582ae14ff141235": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          15m (x4 over 16m)       kubelet            Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  15m                     kubelet            Container image "rancher/coredns-coredns:1.8.3" already present on machine
  Normal   Created                 15m                     kubelet            Created container coredns
  Normal   Started                 15m                     kubelet            Started container coredns
  Warning  Unhealthy               15m                     kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:8181/ready": dial tcp <IP_ADDRESS>:8181: connect: connection refused
  Warning  DNSConfigForming        15m (x9 over 16m)       kubelet            Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: <IP_ADDRESS> <IP_ADDRESS> 2001:558:feed::1
  Warning  BackOff                 15m (x3 over 15m)       kubelet            Back-off restarting failed container
  Warning  FailedCreatePodSandBox  14m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "07a726c282f035352597bd8f0a84561f6af74b803977449e488b3d728a1e7439": open /run/flannel/subnet.env: no such file or directory
  Warning  FailedCreatePodSandBox  14m                     kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "32e9d6bd2c62d97eae2233d0dd4db69d9c723e5e03491c77870fcddf9c0bdeb6": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          12m (x3 over 14m)       kubelet            Pod sandbox changed, it will be killed and re-created.

Jun 02 13:51:41 knode0 systemd[1]: Started Lightweight Kubernetes.
 I see a lot of IPv6 addresses in both the pod logs and the agent logs, but the flannel CNI does not support IPv6 at the moment. Can you try disabling IPv6 on both nodes, and then rebooting?

Thanks @brandond , disabled IPv6 following this guide and seems to be working now 👍🏼 😃

This is not a solution tho, it's a workaround disabling IPv6, which could be needed by some users...


merge rliebz/dvn-client-python into IQSS/dvn-client-python

https://github.com/IQSS/dvn-client-python/pull/5
I reverted the merge I made from @rliebz and since there doesn't seem to be a way to reopen a pull request, I'm creating this issue to track it.

Resolved by 8f10d96f203bbd95a83b3c55577a7bcf984c743c


Fix adding policy action of type remove or inherit tags

Classification has custom find_by_name that looks up tag by name and classification by tag id
That got broken by the rails4 rewrite, this commit restores the same logic but on the caller side.
(No other callers call Classification.where(:name => ...)).
Pulled out the find tag by name functionality used in Classification.find_by_name into new Classification.find_tag_by_name so it's a bit cleaner.
Also the label for remove_tags should not say Inherit Tags :)
https://bugzilla.redhat.com/show_bug.cgi?id=1205496

I like the method extraction, but can you include tests please?  I guess the extracted method is untested (unless the UI tests are covering it?)

Verified fix in the UI . . . awaiting test.

Moved the method to Tag, tests added, please review as this is one of my first tests :).

test, looks good.


tECDSA signing: Consistent party key between TSS runs

Refs: https://github.com/keep-network/keep-core/issues/3042
Depends on: https://github.com/keep-network/keep-core/pull/3251
So far, we were doing a simple mapping between the group.MemberIndex and the TSS party key for both tECDSA DKG and signing. Unfortunately, this turned out to be wrong. The TSS party key generated based on the group.MemberIndex has an impact on the private key share produced as a DKG result which means the same TSS party key must be used by the share's holder during the signing. However, our DKG implementation contains a path where the final group.MemberIndex of a member can differ from the original group.MemberIndex used during protocol execution. That typically takes place when the DKG process completes with misbehaved members that must be excluded from the final signing group. As result, the group.MemberIndex <-> TSS party key mapping logic does not work for the aforementioned case and makes signature generation impossible if the signing group was generated with misbehaved members.
To make it work, we need to make sure that the key used to identify the party during a TSS execution is preserved between runs. We achieve that by introducing different mapping logic for DKG and signing.
For DKG, the TSS party key is now constructed by taking the group.MemberIndex and adding it to the DKG seed. The seed component allows avoiding confusion between the group.MemberIndex and party key and also ties the TSS keys to a given DKG instance. Here is how it works for an example DKG run:

Seed: 200
Member indexes: [1, 2, 3, 4, 5]
TSS keys: [201, 202, 203, 204, 205]

If member 3 misbehaves and gets excluded from the final signing group, the member indexes and TSS keys arrays will look as follows:

Member indexes: [1, 2, 4, 5]
TSS keys: [201, 202, 204, 205]

The final member indexes must be shifted accordingly but TSS keys must remain the same since they are connected with specific private key shares held by members:

Member indexes: [1, 2, 3, 4]
TSS keys: [201, 202, 204, 205]

For signing, member 1 must use key 201, member 2 must use key 202, and so on. Fortunately, each key share contains the full TSS keys list used during DKG as a reference. That information is held in the Ks field, and now we are using it to map the group.MemberIndex to a proper TSS party key during the signing.
Next steps
This PR is just a part of the entire work regarding the tECDSA signing test loop. Please refer to the description of https://github.com/keep-network/keep-core/issues/3042 for the full roadmap and the current status of the work. At this point, the next step will be introducing the retry algorithm.

I am not sure I fully understand the conversion requirements but I think that if we agree to eliminate adding the seed when constructing the tss.PartyID for key generation, we can eliminate the converter and have just three functions in common package.
I looked at tss-lib README and it does not mention the party ID has to be a large number. Is there something in the protocol that is not mentioned there?
I tried to put everything together to fully understand the process.
 We receive an array of 100 operators selected to the signing group by the sortition pool.
Each operator has its member index assigned, based on the position in the array. selected[0] has member index = 1, selected[1] has member index = 2,…, selected[99] has member index = 100.
When the DKG attempt fails, some members are excluded from the next attempt. The exclusion algorithm provides indexes of members excluded from the next run.
During the execution of a retry of a DKG protocol, indexes are not getting shifted. For example, if the original selection was [0xA, 0xB, 0xC, 0xD, 0xE] and operator 0xC has been excluded from the attempt, the member indexes stay as 1 (0xA), 2 (0xB), 4 (0xD), 5 (0xE). This allows filtering out messages from excluded members using pkg/protocol/group/membership_validator.go that is created based on the sortition result, before the retry loop.
Once DKG completes successfully, indexes of members excluded from the execution must be set in EcdsaDkg.Result.misbehavedMembersIndices and EcdsaDkg.Result.membersHash should have the misbehaving members filtered out. When the DKG result gets approved, EcdsaDkg.dkgResult.membersHash is stored on-chain.
When establishing the transaction submission order when publishing the result to the chain, we take into account the original selection result and we do not skip misbehaving members. It means that the submission may take a bit longer but is more predictable and less complex.
Before saving information to disk, misbehaving members are excluded from the result and the member indexes are shifted in node.go’s finalSigningGroup function. It make sense because first, we do not want to have unnecessary delays when determining the order for publishing a signature, and second, if we need to round-robin the responsibility of proposing the sweep batch, we also do not want unnecessary delays.

We could have a simple mapping logic: MemberIndex(1) <-> tss.PartyID(1), MemberIndex(2) <-> tss.PartyID(2), …
And then, the mapping logic would be simple:
MemberIndexToTssPartyID(memberIndex group.MemberIndex) *tss.PartyID {
  key := big.NewInt(memberIndex)
  return tss.NewPartyID(key.Test(10), fmt.Sprintf(“member-%v”, memberIndex), key)
}

TssPartyIDToMemberIndex(partyID *tss.PartyID) group.MemberIndex {
  return group.MemberIndex(partyID.KeyInt())
}

There is a catch though! tssParty.UpdateFromBytes(…) function requires the tss.PartyID passed as a parameter to have an index set and the index is set by the library when tss.PartyIDs are sorted into tss.SortedPartyIDs. The explanation of it is that the tss-lib protocol has its own party indexes inside (similar to our group.MemberIndex) and it needs to sort tss.PartyIDs based on the arbitrary Key value. Note that from the perspective of tss-lib there is no guarantee the Keys used to construct tss.PartyIDs were all increasing by 1. They could be large, random numbers as well. It’s only specific to our code that these numbers are {1,2,…100}.
Then, we need one more function in common:
MemberIndexToSortedTssPartyID(memberIndex group.MemerIndex, tssParameters *tss.Parameters) *tss.PartyID {
  sortedPartiesIDs := tssParameters.Parties().IDs()
  key := big.NewInt(memberIndex)
  return sortedPartiesIDs.FindByKey(key)
}

That function would be used instead of ResolveSortedTssPartyID.
Signing

When DKG result is stored on disk, every signing group member stores tecdsa.PrivateKeyShare. This structure includes privateKeyShare.Data().Ks which is []*big.Int of party ID keys. The member indexes reconstructed from this array will correspond to the ones published to the chain, that is, with misbehaving members filtered out.
Group member info saved to disk has the indexes shifted as noted in point 7 of Key generation section, so if we agree for a simple mapping logic where MemberIndex(1) <-> tss.PartyID(1), then we do not need a separate converter for signing and I believe we can use the same logic as for the key generation.

My reasoning in the previous comment was not valid. I did not take into account that when we shift indexes in the key generation algorithm at point 7, these indexes no longer match the ones in Ks.

The successful DKG run DOES NOT have the member indexes shifted. So if the successful DKG run was with [MemberIndex(1), MemberIndex(3), MemberIndex(5)], the TSS Party IDs will be [PartyID(1), PartyID(3), PartyID(5)].
We DO SHIFT member indexes before submitting the result to the chain and saving the result on-disk. Hence, the indexes saved on disk will be [MemberIndex(1), MemberIndex(2), MemberIndex(3)].
They DO NOT match  [PartyID(1), PartyID(3), PartyID(5)] saved in Ks.


HeidelbergUniversity.GaiaSky version 3.5.1

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/112785&drop=dogfoodAlpha

If merged, close issue #112594


Feature 25 22 18 upgrade dependencies gosec report bug

fixes loading of GoSec reports #22 #18
upgrade dependencies #25
add support for secret scan #23
improve README for developers

This pull request closes:

closes: #25
closes: #23
closes: #22
closes: #18

The test are running through. However, there are two possible paths executing npm test or xvfb-run -a npm test. Only the path using xvfb-run -a npm test is used by the GitHub Action environment. xvfb-run provides the necessary frame buffer. As a result, the npm test command in never executed inside the container.

The test are running through. However, there are two possible paths executing npm test or xvfb-run -a npm test. Only the path using xvfb-run -a npm test is used by the GitHub Action environment. xvfb-run provides the necessary frame buffer. As a result, the npm test command in never executed inside the container.

Funny:
https://github.com/mercedes-benz/sechub-plugin-vscode/commit/89e2fd0325b6da19e0fc6c5ecfbc1f0720572ca7
was added by myself, but I did no longer remembered that this was necessary...
Sorry.


FIB lookup failed in cilium dualstack scenario in AKS

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
This issue happens in dualstack cluster in AKS using cilium. When user creates k8s service type loadbalancer, health probes are failing to respond. Upon investigation found LB health probes are sent from link local source address which cannot be forwarded fe80::1234:5678:9abc. To workaround this, added nftable rules to change source IP to global unicast ip for request and convert back to original destination IP in return. This workaround seems to be working in other CNI clusters with kube-proxy but not in cilium with kube-proxy replacement clusters. The return packets are not getting forwarded and failing with FIB_LOOKUP_FAILED error. The following is the error log from cilium monitor
xx drop (FIB lookup failed, 4) flow 0xb902961c to endpoint 0, ifindex 2, file nodeport.h:1533, , identity unknown->unknown: [fd4d:d4a6:3301:b26a::193]:80 -> [fe80::1234:5678:9abc]:51516 tcp SYN, ACK
Setup Details
CloudProvider: AKS
CiliumConfig: IPv6Enabled, native routing, delegated ipam. Attached sysdump
NodeIP: fde9:48a7:d155:3659::5/128
PodIP: fd4d:d4a6:3301:b26a::193
NodePort: 32260
HealthProbe port: 32260
Healthprobe Src: fe80::1234:5678:9abc (link local)
Healthprobe dst: fde9:48a7:d155:3659::5(nodeip)
nftable modified src ip for health probe: 2603:1062:0:1:fe80:1234:5678:9abc
nftable rules:
define slb_lla = fe80::1234:5678:9abc
define slb_gua = 2603:1062:0:1:fe80:1234:5678:9abc

table ip6 azureSLBProbe
delete table ip6 azureSLBProbe

table ip6 azureSLBProbe {
    chain prerouting {
        type filter hook prerouting priority -300;

        # Add a rule that accepts router discovery packets without mangling or ipv6 breaks after
        # 9000 seconds when the default route times out
        iifname eth0 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } counter accept

        # Map packets from the LB probe LLA to a SLA IP instead
        iifname eth0 ip6 saddr $slb_lla ip6 saddr set $slb_gua counter
    }
    chain postrouting {
        type filter hook postrouting priority -300;

        # Reverse the modification on the way back out
        oifname eth0 ip6 daddr $slb_gua ip6 daddr set $slb_lla counter
    }
}

tcpdump capture on VM eth0 (netdevice)
root@aks-nodepool1-35563861-vmss000001:/# tcpdump -ni eth0 -e ip6 and port 32260

19:44:18.758596 96:18:ae:2c:b4:56 > 4e:0e:70:5d:de:25, ethertype IPv6 (0x86dd), length 86: 2603:1062:0:1:fe80:1234:5678:9abc.51516 > fd4d:d4a6:3301:b26a::193.80: Flags [SEW], seq<PHONE_NUMBER>, win 64800, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0

Health port is same as nodeport which is 32260 and from above, we could see health probes are coming from link local source address to nodeip:nodport
tcpdump capture on pod host veth (lxcb044218ddd3e):
root@aks-nodepool1-35563861-vmss000001:/# tcpdump -nli lxcb044218ddd3e -e ip6 and port 80

19:44:19.763563 96:18:ae:2c:b4:56 > 4e:0e:70:5d:de:25, ethertype IPv6 (0x86dd), length 86: 2603:1062:0:1:fe80:1234:5678:9abc.51516 > fd4d:d4a6:3301:b26a::193.80: Flags [SEW], seq<PHONE_NUMBER>, win 64800, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0
19:44:19.763588 4e:0e:70:5d:de:25 > 96:18:ae:2c:b4:56, ethertype IPv6 (0x86dd), length 86: fd4d:d4a6:3301:b26a::193.80 > 2603:1062:0:1:fe80:1234:5678:9abc.51516: Flags [S.], seq 277372771, ack<PHONE_NUMBER>, win 64800, options [mss 1440,nop,nop,sackOK,nop,wscale 7], length 0

From above, you could see nftable prerouting rule changing src ip from fe80::1234:5678:9abc to 2603:1062:0:1:fe80:1234:5678:9abc and also there is return packet with syn+ack back from the pod but this return packet doesn't  get to eth0. Looks like cilium dropped this packet due to this error:
xx drop (FIB lookup failed, 4) flow 0xb902961c to endpoint 0, ifindex 2, file nodeport.h:1533, , identity unknown->unknown: [fd4d:d4a6:3301:b26a::193]:80 -> [fe80::1234:5678:9abc]:61358 tcp SYN, ACK
Error code 4 indicates BPF_FIB_LKUP_RET_NOT_FWDED. I hope this means packet cannot be forwarded. This is confusing to me because as per nftable rule the return packet (syn+ack) destination ip should be changed to  original src ip (fe80::1234:5678:9abc) only in POSTROUTING chain and if output interface name matches eth0. Based on above error, looks like fib_lookup happens after destination IP got changed. Does fib lookup happen after packet routed to node nic eth0? Looking for some guidance on how we can solve this issue.
Cilium Version
1.14.4
Kernel Version
Linux aks-nodepool1-35563861-vmss000001 5.15.0-1057-azure #65-Ubuntu SMP Fri Feb 9 18:39:24 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Kubernetes Version
1.29
Regression
No response
Sysdump
cilium-sysdump-20240311-130541.zip
Relevant log output
No response
Anything else?
No response
Cilium Users Document

[X] Are you a user of Cilium? Please add yourself to the Users doc

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Some related discussion here - https://github.com/cilium/cilium/issues/30450

Some related discussion here - #30450

@nickolaev seems to be not related to above issue

Seem like this has been tackled in https://github.com/Azure/azure-container-networking/pull/2710

@tamilmani1989 can we close this issue now that 2710 has been merged and public preview for the feature is available as well?


[path_provider_linux] Migration to null safety

Description
Migrates path_provider_linux to null safety.
Related Issues
Fixes https://github.com/flutter/flutter/issues/70219
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
[x] All existing and new tests are passing.
[x] I updated/added relevant documentation (doc comments with ///).
[x] The analyzer (flutter analyze) does not report any problems on my PR.
[x] I read and followed the Flutter Style Guide.
[x] The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
[x] I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
[x] I updated CHANGELOG.md to add a description of the change.
[x] I signed the CLA.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (please indicate a breaking change in CHANGELOG.md and increment major revision).
[x] No, this is not a breaking change.

Hey @ditman kindley have a look at this one.

Analyze is not getting passed because there is no environment set in connectivity plugin's pubspec.yaml, should I add that in this PR?

@Hixie I think the analyze test errors are not related to this PR.

Sorry for the late notice. The nnbd branch has been merged into master.
You might need to reopen this PR.

Sure I'll reopen the PR on master branch.


Bring Bayly's latest envMoves examples from his branch into environment branch, updating existing PR #112

I would like to have @cbayly13 's example ipython notebooks in the environment branch. I think everything they are testing fits within the current WIP pull request #112

Thanks, sounds good. I just changed the name of this to describe what it actually does.
(Names might not seem important right now but they can be very helpful when looking back at a history of changes, which is sometimes necessary.)


More flexible layer storage

Layers currently have distinct fields for the label of the regulation component they are referencing as well as the version of that regulation. As we'd like to start creating layers for other entities (namely, preambles), this generalizes that conception to a single "reference" string which includes both version and label when referring to regulations.
Read and write interfaces for the layer model also needed to be updated. See individual changesets for a more in-depth story. Note that there's nothing here to prevent a namespace collision; we're keeping relatively closely with the key-value storage approach.
Should resolve eregs/notice-and-comment#17

I'm guessing this isn't an issue, but could preamble labels ever conflict with regulation versions, so that the delete in bulk_put would unintentionally delete unrelated layer records?

This is handled okay on the insertion side (in practice, the namespaces are different), but you bring up a great point about the "startswith" deletion. Preambles could delete reg data (if both share the same document number). It'd make more sense to namespace everything (e.g. "cfr:version:label" for regs and "preamble:label" for preambles).
This isn't an issue we'll encounter for a bit, however (we won't have a document number until at least next sprint). I think we're okay to make an issue but get this PR in now.


URLs that stay the same when a file is replaced. Fixes #478

Sometimes users share the direct URL of public files. But whenever they update the file in the "advanced" panel on the file's admin page, the direct URL changes as well.
Perhaps django-filer could include a canonical URL that redirects to the latest version of a public file and that can be shared safely:

If they wish to use canonical URLs, users need to include filer's URLConf in their project's urls.py. If they don't configure their project that way, or if they create a non-public file, the filer admin does not display a canonical URL.

@jvamvas really nice
:+1: from me

@stefanfoulis @mkoistinen is this good for you?
If so I'll resolve the conflicts and merge it myself

@yakky :+1: from me :-)

@jvamvas merged. Thanks a lot for tour great work


Intercoms are very undercooked

Description

You cannot insert encryption keys into Intercoms, nor can you even deconstruct them (which is a big problem given that you can make them.)

Intercoms honestly need a rework anyways if we want AI out before release, but thats a different issue.

Fixed by #29580


chore: enable iam policy minimization

Update cdk version and add feature flag to enable IAM policy
minimization to dev app. This will greatly reduce the size of policies generated
for various roles that would have exceeded the limit when adding Go
language support.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Draft pending testing on my personal account.


Mapchange won't start

Description
After the last update it does not change the map and returns me this error in the server side console

[Partly Adequate Mapvote] lua/includes/extensions/table.lua:693: bad argument #1 to 'pairs' (table expected, got nil)

pairs - [C]:-1
GetKeys - lua/includes/extensions/table.lua:693
3. PrintTable - lua/includes/util.lua:63
4. unknown - lua/pam/server/sv_pam.lua:106

Timer Failed<EMAIL_ADDRESS>(line 81)]
PS: also the cvar dosen't store for my and after server restart they reset

Thanks for letting me know.
I was missing a nil check. It should be fixed now.
The convars not saving is a problem i can't reproduce momentarily. It seems to work on my machine.


[INLONG-4763][Sort] Import sort end2end unit test with sql file input

Prepare a Pull Request
(Change the title refer to the following example)

Fixes #4763

Modifications
Import sort end2end unit test with sql file input

i will move this module to inlong root module later in #4808

@thesumery please add licenses for new dependencies.

ok , add new dependency testcontainer LICENSE. testcontainer don't have NOTICE file, so NOTICE don't need to change.

ok , add new dependency testcontainer LICENSE. testcontainer don't have NOTICE file, so NOTICE don't need to change.

Do not need to add LICENSE for testcontianer , because it is only used in test scope.


TypeScript Support

Benefits of native TypeScript include:

Strong autocomplete
Easier refactoring
Code documentation

The underlying library warcio.js was also recently ported to TypeScript.

Appreciate the suggestion :).
I believe we have pretty good support for the three elements you listed with JSDoc, with the added benefits of not having a build step and being able to copy/paste code in the REPL.

Ahh, I was involved with porting warcio.js to TypeScript, and was looking into doing the same here :)

not having a build step

Unfortunately, if you are looking to target browsers in https://github.com/harvard-lil/js-wacz/issues/14, you will still need a build step with babel for backwards compatibility

being able to copy/paste code in the REPL

ts-node features a TypeScript REPL environment

While JSDoc can be used for type information, you will likely need // @ts-check at the top of your files and additional linter rules (such as eslint-plugin-jsdoc) to receive the benefits of static typing.  That way, you will have errors if your code is missing JSDoc types or if the JSDoc types don’t actually match your code.
In addition, I find that TypeScript syntax less verbose and more readable than JSDoc, and more developers are familiar with TypeScript than JSDoc.

I understand :).
Since there is no blocker on documentation, auto-complete or - as you noted - type checking, I think the library would benefit most from time investment elsewhere at the moment.
An additional factor is that we are developing and maintaining multiple JavaScript + JSDoc codebases at the moment, so this is where we are focusing our efforts on.
It is therefore unlikely we'll port to TypeScript anytime soon, but I'm happy to revisit further down the road if either of those things change.

PS: Also happy to consider adding @ts-check flags to enforce type checking via JSDoc if its helpful for folks whose editor doesn't support that feature without it. Let me know 😄 .


sorry, wrong repo.

sorry, wrong repo.

No problem :)

Hi, @bsansouci . Do you use this repo in your ghost blog?
I met some bug when use the official ghost: https://github.com/TryGhost/Ghost/issues/5632 .
Actually, the bug was fixed in latest version of showdown, so, Is there any possible to  you to update your repo to latest showdown?


KeyError: 'saved_prompts'

this issue appears after just updating the rgthree, and I see the new commit about 'saved_prompts'
comfyui python3.10+torch2.3.1+cu121, the messages in console is:
[ERROR] An error occurred while retrieving information for the 'SDXL Power Prompt - Simple / Negative (rgthree)' node.
Traceback (most recent call last):
File "F:\ComfyUI-aki-v1.4\server.py", line 579, in get_object_info
out[x] = node_info(x)
File "F:\ComfyUI-aki-v1.4\server.py", line 546, in node_info
info['input'] = obj_class.INPUT_TYPES()
File "F:\ComfyUI-aki-v1.4\custom_nodes\rgthree-comfy\py\sdxl_power_prompt_simple.py", line 24, in INPUT_TYPES
saved_prompts_files = folder_paths.get_filename_list('saved_prompts')
File "F:\ComfyUI-aki-v1.4\folder_paths.py", line 334, in get_filename_list
out = get_filename_list_(folder_name)
File "F:\ComfyUI-aki-v1.4\folder_paths.py", line 295, in get_filename_list_
folders = folder_names_and_paths[folder_name]
KeyError: 'saved_prompts'

Yep, same here.

this issue also in comfyui 0.38 python3.12+torch2.5.1+cu124.
Comfyui started completely, and issue appears with the front ui raising.

Oops, forgot a spot. Thanks, should be good with an update.


CUDA Setup failed despite GPU being available.

System Info
OS: windows 11
Python: 3.10.11
CPU: Intel(R) Xeon(R) Gold 6134 CPU
GPU: Nvidia RTX A5000
Reproduction
nvcc:
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2024 NVIDIA Corporation
Built on Wed_Oct_30_01:18:48_Pacific_Daylight_Time_2024
Cuda compilation tools, release 12.6, V12.6.85
Build cuda_12.6.r12.6/compiler.35059454_0
python -m bitsandbytes:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++ BUG REPORT INFORMATION ++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++ OTHER +++++++++++++++++++++++++++
CUDA specs: CUDASpecs(highest_compute_capability=(8, 6), cuda_version_string='124', cuda_version_tuple=(12, 4))
PyTorch settings found: CUDA_VERSION=124, Highest Compute Capability: (8, 6).
To manually override the PyTorch CUDA version please see: https://github.com/TimDettmers/bitsandbytes/blob/main/docs/source/nonpytorchcuda.mdx
The directory listed in your path is found to be non-existent: \CHONG
CUDA SETUP: WARNING! CUDA runtime files not found in any environmental path.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++ DEBUG INFO END ++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Checking that the library is importable and CUDA is callable...
SUCCESS!
Installation was successful!
pip show bitsandbytes:
Name: bitsandbytes
Version: 0.45.0
Summary: k-bit optimizers and matrix multiplication routines.
Home-page: https://github.com/bitsandbytes-foundation/bitsandbytes
Author: Tim Dettmers
Author-email<EMAIL_ADDRESS>License: MIT
Location: c:\users\admin\appdata\local\packages\pythonsoftwarefoundation.python.3.10_qbz5n2kfra8p0\localcache\local-packages\python310\site-packages
Requires: numpy, torch, typing_extensions
Required-by:
error:
File "Q:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\bitsandbytes\optim_init_.py", line 6, in
from bitsandbytes.cextension import COMPILED_WITH_CUDA
File "Q:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\bitsandbytes\cextension.py", line 20, in
raise RuntimeError('''
RuntimeError:
CUDA Setup failed despite GPU being available. Please run the following command to get more information:
    python -m bitsandbytes

    Inspect the output of the command and see if you can locate CUDA libraries. You might need to add them
    to your LD_LIBRARY_PATH. If you suspect a bug, please take the information from python -m bitsandbytes
    and open an issue at: https://github.com/TimDettmers/bitsandbytes/issues

The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "Q:\ComfyUI_windows_portable\ComfyUI\nodes.py", line 2035, in load_custom_node
module_spec.loader.exec_module(module)
File "", line 940, in exec_module
File "", line 241, in call_with_frames_removed
File "Q:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-HunyuanVideoWrapper_init.py", line 1, in
from .nodes import NODE_CLASS_MAPPINGS, NODE_DISPLAY_NAME_MAPPINGS
File "Q:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-HunyuanVideoWrapper\nodes.py", line 12, in
from .hyvideo.modules.posemb_layers import get_nd_rotary_pos_embed
File "Q:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-HunyuanVideoWrapper\hyvideo\modules_init_.py", line 1, in
from .models import HYVideoDiffusionTransformer, HUNYUAN_VIDEO_CONFIG
File "Q:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-HunyuanVideoWrapper\hyvideo\modules\models.py", line 8, in
from diffusers.models import ModelMixin
File "", line 1229, in _handle_fromlist
File "Q:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\diffusers\utils\import_utils.py", line 843, in getattr
module = self._get_module(self._class_to_module[name])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "Q:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\diffusers\utils\import_utils.py", line 855, in _get_module
raise RuntimeError(
RuntimeError: Failed to import diffusers.models.modeling_utils because of the following error (look up to see its traceback):
    CUDA Setup failed despite GPU being available. Please run the following command to get more information:

    python -m bitsandbytes

    Inspect the output of the command and see if you can locate CUDA libraries. You might need to add them
    to your LD_LIBRARY_PATH. If you suspect a bug, please take the information from python -m bitsandbytes
    and open an issue at: https://github.com/TimDettmers/bitsandbytes/issues

Cannot import Q:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-HunyuanVideoWrapper module for custom nodes: Failed to import diffusers.models.modeling_utils because of the following error (look up to see its traceback):
    CUDA Setup failed despite GPU being available. Please run the following command to get more information:

    python -m bitsandbytes

    Inspect the output of the command and see if you can locate CUDA libraries. You might need to add them
    to your LD_LIBRARY_PATH. If you suspect a bug, please take the information from python -m bitsandbytes
    and open an issue at: https://github.com/TimDettmers/bitsandbytes/issues

Total VRAM 24564 MB, total RAM 195180 MB
pytorch version: 2.4.1+cu124
Set vram state to: NORMAL_VRAM
Device: cuda:0 NVIDIA RTX A5000 : cudaMallocAsync
Expected behavior
Would like to run without errors. Any help would be appreciated.

same question on windowsServer2022,python 3.10

For anybody with a similar problem:
Comfyui was using an embeded python version. Installing bitsandbytes through comfyui manager then install pip packages solved the issue.


improve text

Anytime!

Anytime!

Sorry, I thought it was merged

Sorry, I thought it was merged


Improve plugin performance and fix Nacos IT instability. fix #2837

Please answer these questions before submitting pull request

Why submit this pull request?

[ ] Bug fix

[ ] New feature provided

[x] Improve performance

Related issues

fixes #2837

New feature or improvement

Describe the details and related test reports.

replace String.format with + operator

Coverage remained the same at 17.287% when pulling 96616ada1266ab0002e1d9946275fbe0bad27083 on kezhenxu94:gh/2837 into 7f2277091dcab2ee7c2cabb414622d4fd99064e8 on apache:master.

Also, you CI is failing, please fix it.

Also, you CI is failing, please fix it.

It's weird that it failed on OracleJDK but passed on OpenJDK, now the master branch failed too. I need to do some research on this

Because of configuration-nacos?

@kezhenxu94 See this, https://travis-ci.org/apache/skywalking/builds/543132461 .
Look like nacos test is not stable,  read log https://travis-ci.org/apache/skywalking/jobs/543132463
We need to figure some method or remove this test case somehow.

[ERROR] DOCKER> [nacos/nacos-server:1.0.0] "nacos-dynamic-configuration-integration-test-nacos": Timeout after 60293 ms while waiting on log out 'Nacos started successfully'
[ERROR] DOCKER> Error occurred during container startup, shutting down...
[ERROR] DOCKER> I/O Error [[nacos/nacos-server:1.0.0] "nacos-dynamic-configuration-integration-test-nacos": Timeout after 60293 ms while waiting on log out 'Nacos started successfully']
[ERROR] Failed to execute goal io.fabric8:docker-maven-plugin:0.28.0:start (start) on project configuration-nacos: I/O Error: [nacos/nacos-server:1.0.0] "nacos-dynamic-configuration-integration-test-nacos": Timeout after 60293 ms while waiting on log out 'Nacos started successfully' -> [Help

Nacos test starts up slowly.

[ERROR] DOCKER> [nacos/nacos-server:1.0.0] "nacos-dynamic-configuration-integration-test-nacos": Timeout after 60293 ms while waiting on log out 'Nacos started successfully'
[ERROR] DOCKER> Error occurred during container startup, shutting down...
[ERROR] DOCKER> I/O Error [[nacos/nacos-server:1.0.0] "nacos-dynamic-configuration-integration-test-nacos": Timeout after 60293 ms while waiting on log out 'Nacos started successfully']
[ERROR] Failed to execute goal io.fabric8:docker-maven-plugin:0.28.0:start (start) on project configuration-nacos: I/O Error: [nacos/nacos-server:1.0.0] "nacos-dynamic-configuration-integration-test-nacos": Timeout after 60293 ms while waiting on log out 'Nacos started successfully' -> [Help

Nacos test starts up slowly.

It passed again, I'll try to increase the timeout

@kezhenxu94 See this, https://travis-ci.org/apache/skywalking/builds/543132461 .
Look like nacos test is not stable, read log https://travis-ci.org/apache/skywalking/jobs/543132463
We need to figure some method or remove this test case somehow.

The problem that Nacos starts timeout has been resolved because the database is not initialized properly, now the reason why it fails became stable:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.22.0:verify (default) on project configuration-nacos: There are test failures.
[ERROR]
[ERROR] Please refer to /home/travis/build/apache/skywalking/oap-server/server-configuration/configuration-nacos/target/failsafe-reports for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, [date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?
[ERROR] Command was /bin/sh -c cd /home/travis/build/apache/skywalking/oap-server/server-configuration/configuration-nacos && /usr/lib/jvm/java-8-oracle/jre/bin/java -javaagent:/home/travis/.m2/repository/org/jacoco/org.jacoco.agent/0.8.3/org.jacoco.agent-0.8.3-runtime.jar=destfile=/home/travis/build/apache/skywalking/oap-server/server-configuration/configuration-nacos/target/jacoco.exec -jar /home/travis/build/apache/skywalking/oap-server/server-configuration/configuration-nacos/target/surefire/surefirebooter4815176584272407938.jar /home/travis/build/apache/skywalking/oap-server/server-configuration/configuration-nacos/target/surefire 2019-06-08T16-52-43_685-jvmRun1 surefire9151435006599987077tmp surefire_13688043696340956275tmp
[ERROR] Process Exit Code: 0

// more stack trace ...

After Googling for a while, I cannot figure out why it happens yet.

It sill failed occasionally, and I did not figure out why after struggling half a day, I'm afraid that I have to remove the test case temporarily

Then, I think we should remove it. Do you know jenkins in better way? I want to move more ci to ASF jenkins, are you interesting?

Then, I think we should remove it.

I'll send another PR to remove the test temporarily.

Do you know jenkins in better way? I want to move more ci to ASF jenkins, are you interesting?

I'm interested in this though I know little about Jenkins, but as far as I know in the Apache Dubbo Mailing List, configuring Jenkins job in ASF's infra needs more privileges, will do some research about Jenkins CI first and ping you

I have the privilege, as I am project vp and apache officer. Send me your Apache id private, I will grant that to you.


Remove a Bogus Assertion

The self type in this routine is absolutely allowed to resolve to an
Optional.
rdar://74557857

@swift-ci smoke test and merge


LR schedulers do not work in R

Neither custom nor pre-built learning rate schedulers have any effect on the training process in R.
The training process is always the same regardless of the scheduling scheme used.
Some debugging shows that the lr_scheduler function is called and the LR is correctly recalculated, however the updated LR is not applied.
I have a strong suspicion that the issue is a side-effect of commit be478700e01944ecfee0c30a7cc5dc07d1b2789a (#11374)
in R-package/R/optimizer.R.
Before it, the LR was used in update calculations directly. Now the LR is baked-in in the executor and is never actually updated.

Minimal example
I hope it will be of some help. Modified after the tutorial.
Code
data(BostonHousing, package="mlbench")

train.ind = seq(1, 506, 3)
train.x = data.matrix(BostonHousing[train.ind, -14])
train.y = BostonHousing[train.ind, 14]

data <- mx.symbol.Variable("data")
fc1 <- mx.symbol.FullyConnected(data, num_hidden=1)
lro <- mx.symbol.LinearRegressionOutput(fc1)

cat("Without scheduler\n")
mx.set.seed(0)
model1 <- mx.model.FeedForward.create(lro, X=train.x, y=train.y,
    ctx=mx.cpu(),     num.round=20, array.batch.size=20,
    learning.rate=2e-6, momentum=0.9,  eval.metric=mx.metric.rmse)

cat("\nWith scheduler\n")
lr_scheduler <- mx.lr_scheduler.FactorScheduler(
    step = 5 * ceiling(length(train.y)/20), factor = 0.1,
    stop_factor_lr = 1e-10)
mx.set.seed(0)
model2 <- mx.model.FeedForward.create(lro, X=train.x, y=train.y,
    ctx=mx.cpu(),     num.round=20, array.batch.size=20,
    learning.rate=2e-6, momentum=0.9,  eval.metric=mx.metric.rmse,
    lr_scheduler = lr_scheduler)

Output
Without scheduler
Start training with 1 devices
[1] Train-rmse=18.0516391330295
[2] Train-rmse=13.9097522099813
[3] Train-rmse=10.666042221917
[4] Train-rmse=10.0117386711968
[5] Train-rmse=9.59162097507053
[6] Train-rmse=9.80227173699273
[7] Train-rmse=9.56405830383301
[8] Train-rmse=9.39033126831055
[9] Train-rmse=9.33245415157742
[10] Train-rmse=9.31073543760512
[11] Train-rmse=9.27919896443685
[12] Train-rmse=9.24656009674072
[13] Train-rmse=9.206680615743
[14] Train-rmse=9.17186906602648
[15] Train-rmse=9.14681609471639
[16] Train-rmse=9.12289328045315
[17] Train-rmse=9.09742567274306
[18] Train-rmse=9.0733421113756
[19] Train-rmse=9.05105861028036
[20] Train-rmse=9.02993933359782

With scheduler
Start training with 1 devices
[1] Train-rmse=18.0516391330295
[2] Train-rmse=13.9097522099813
[3] Train-rmse=10.666042221917
[4] Train-rmse=10.0117386711968
[5] Train-rmse=9.59162097507053
Update[46]: learning rate is changed to 2e-07
[6] Train-rmse=9.80227173699273
[7] Train-rmse=9.56405830383301
[8] Train-rmse=9.39033126831055
[9] Train-rmse=9.33245415157742
[10] Train-rmse=9.31073543760512
Update[91]: learning rate is changed to 2e-08
[11] Train-rmse=9.27919896443685
[12] Train-rmse=9.24656009674072
[13] Train-rmse=9.206680615743
[14] Train-rmse=9.17186906602648
[15] Train-rmse=9.14681609471639
Update[136]: learning rate is changed to 2e-09
[16] Train-rmse=9.12289328045315
[17] Train-rmse=9.09742567274306
[18] Train-rmse=9.0733421113756
[19] Train-rmse=9.05105861028036
[20] Train-rmse=9.02993933359782
Warning messages:
1: In mx.model.select.layout.train(X, y) :
  Auto detect layout of input matrix, use rowmajor..

2: In mx.model.select.layout.train(X, y) :
  Auto detect layout of input matrix, use rowmajor..

Train-rmse is the same in every iteration regardless of the scheduler used.

@jeremiedb well, it is not an optimal solution, of course, but I believe it is better than nothing at all. In the worst case scenario, one can reduce the frequency of LR updates to get reasonable training speed.


Scope of Polly polices in relation to named HttpClient configurations

Not so much an issue as drawing out the below implication, and noting it for consideration for documentation
Scope of Polly polices in relation to named HttpClient configurations
Ensuring circuit-breaker and bulkhead policies maintain consistent state while handlers and HttpClient instances are recycled underneath them, has suggested they should be singleton per named HttpClient configuration on HttpClientFactory.
The stateful nature of circuit-breaker and bulkhead policies also has intended functional consequences when sharing policies across call sites:
Circuit-breaker: Sharing a CircuitBreakerPolicy instance at multiple call sites causes those call sites to share circuit statistics and state, and thus to break in common.
This is intended: for example, using the same CircuitBreakerPolicy instance for all calls to (various endpoints on) contoso.com means any call you place to any endpoint on contoso.com can know if other calls have already detected that contoso.com is 'down' (and broken the circuit).
Bulkhead: Calls placed through the same BulkheadPoliy instance share the capacity of that bulkhead.

The corollary of this for HttpClientFactory is:
Circuit-breaker: Where a named HttpClient configuration on an HttpClientFactory uses a CircuitBreakerPolicy, that named HttpClient should be usage-scoped to calls to endpoints the user wishes to break in common.
This is a good fit for the examples @rynowak / @glennc have given for HttpClientFactory, with eg a named client configuration of "github" being used with a BaseUri "github.com" (with the implication calls through it will be to somewhere on github.com).
Bulkhead: Similarly, a named HttpClient configuration, if configured with a BulkheadPolicy, should be usage-scoped to calls the user wishes to share that bulkhead capacity.

Thanks, this is a great answer to some of the questions I have. A few thoughts.
Our 'builder' methods that take a lambda will close over the policy in question when invoked, preventing the policy from being created multiple times.
When a developer wants to share a policy between multiple named handlers, it sounds like they can either write code like this:
var myPolicy = Policy....; // create a policy once

services.AddHttpClient("github").AddPolicy(myPolicy);
services.AddHttpClient("facebook").AddPolicy(myPolicy);

Or we could register the policy registry in services and provide convenience methods to attach policy handlers using policies from the registry.

The latter sounds like a grow up story for the former. There's been some discussion of integration with the policy registry in comments and I've added it to my checklist here https://github.com/aspnet/HttpClientFactory/issues/8
I think the extent of our integration with the registry would be to patternize registering the registry in services and accessing policies from it. It seems like a nice to have.

x-ref for anyone landing here: response to PolicyRegistry integration in #8

Closing this as the policy registry work is checked in


merge spill docs to epic branch

@mattsfuller i guess this is what we have already reviewed, right?
I won't be reading this again :)


Consistent naming scheme from sample() methods

Is your feature request related to a problem? Please describe.
There is an inconsistency in parameter names for sample functions. For the method openclean.pipeline.DataPipeline.sample() the parameter for the sample size is called size and the parameter for the random state is called seed. The method openclean.engine.base.OpencleanEngine.sample() the respective parameters are called nand random_state.
Describe the solution you'd like
implement a consistent naming scheme for parameter names of sample functions. Need to agree on parameter names. My suggestion is to use n for the sample size and random_state for the random state parameter.

This issue also affects the constructor for the class openclean.operator.stream.sample.Sample.


We can add a new C language section for all the questions

@championballer what you think about this ?

In my personal opinion we should complete the solution set for the languages that we are currently working on till the winter of code ends and then we can focus on the expansion to other languages. Focusing on too many languages at the same time might not be a great idea, IMO.

ok , so i am closing issue this !


Flaky test: should focus the input before moving the focus to next selectable element

Test started to randomly failing recently, probably related to one of the overlay releases:
Windows 10 IE 11         ✖ test/select-test.html » vaadin-select » overlay opened » should focus the input before moving the focus to next selectable element
  expected spy to have been called exactly once, but it was called 0 times

Appears to be fixed and no longer flaky. Will reopen if we face it again.


[form-checkbox] Checked/Unchecked Indicator

Feature Request
Description

Currently, there is a prop on the terra-form-checkbox called onChange that passes an event to the function passed to the prop. A consumer can determine the value of the component by querying event.target.value in the handler, but there is not a clear way to determine whether or not this is event is fired because the checkbox was checked or not checked. Additionally, there is not a clear way to query component to determine if it is currently checked or unchecked (besides querying the DOM directly with document.getElementById or similar api).
Additional Context / Screenshots

@ Mentions

@andrewnottaviano have you tried using event.currentarget.Checked in your code ?

@andrewnottaviano

A consumer can determine the value of the component by querying event.target.value in the handler, but there is not a clear way to determine whether or not this is event is fired because the checkbox was checked or not checked.

You could use event.currentTarget.checked to determine if the checkbox is checked or not checked in the event handler.

Additionally, there is not a clear way to query component to determine if it is currently checked or unchecked (besides querying the DOM directly with document.getElementById or similar api).

Are you looking for a refCallback prop to attach a ref to your element?

@andrewnottaviano have you tried using event.currentarget.Checked in your code ?

Yes I did since I posted this issue and that solves my problem. Just didn't get back here to close the issue. Thanks @nramamurth and @ShettyAkarsh!


Create start and stop script

Currently .env file is hardcoded and updates from repository are not so trivial. Always the state is dirty.
Target is:

make env.template file that contain tags instead hardcoded values.
make start script that:

checks if .env file is available

if not start a wizard that asks for email and domain and generates .env
if exists check if in existing .env are missing some fields from env.template and add missing ones, by preserving the already available configuration in .env.

once onboarding/update is complete start the containers.

make stop script that stops the containers.

As result provisioning will be limited to only execute start script and providing the values that are asked from the script. For credentials - random value of 16 characters (a-zA-Z0-9):
PWD=$(tr -dc a-zA-Z0-9 </dev/random | head -c 16)

Not needed.


use subList().clear instead of a loop of remove(0)

use subList().clear instead of a loop of remove(0)

Coverage remained the same at 90.56% when pulling 5603fb701bf83c49ff2096b99674a738d36319aa on XenoAmess:use_subList().clear into 715d89d2625b09915feb1dd1b60270842eeffb7a on apache:master.

Well IMO this can improve the speed as:

in most times the list is an ArrayList here in your codes.
when in original codes, each time you remove(0) it calls a System.arraycopy, means the array is copied extra times.
when use sublist.clear(), it actually called list.removeRange, which do only one System.arraycopy, thus far faster.

Hi. do I need a performance benchmark for this pr too?


UI: fix sql exception display

What does this PR do?

Fixes SQL exception message formatting (earlier it used to ignore escape sequence which made the exception hard to read, but now the message is formatted properly)
Fix message overflow from the box issue

Screenshots
Before

After

@xiangfu0 @mayankshriv

I think we would also need the error code to be printed. Although the stack trace is quite useful, the error code is more useful to classify the error.

I think we would also need the error code to be printed. Although the stack trace is quite useful, the error code is more useful to classify the error.

@gortiz The error code I saw was not correct, e.g. In the above screenshot, we got 200 as errorCode. I thought it is not very helpful hence removed it, I can add that back if required.

I think we would also need the error code to be printed. Although the stack trace is quite useful, the error code is more useful to classify the error.

@gortiz The error code I saw was not correct, e.g. In the above screenshot, we got 200 as errorCode. I thought it is not very helpful hence removed it, I can add that back if required.

Please add it back once you got time, thanks!


Fixed spec to make it inline with server

Description
Fixed spec to make it inline with server
Issues Resolved
Related to #155
Related to #159
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@VachaShah can you please take a look and let me know if any more changes are required

@Xtansia, can you please take a look.


fix: close event loop that starts in thread

Problem
The _run_async_in_thread method in the LiquidHandler class was causing ResourceWarning issues related to unclosed sockets. This warning was being raised at the end of pytests in a library of mine that is starting to use PyLabRobot: graphmix.

To reproduce
Set filterwarnings = error in pytest.ini:

[pytest]
python_files = *_tests.py

filterwarnings =
    error

Solution
Added loop.close() to the end of the callback in _run_async_in_thread to close the event loop that gets created for the callback.
Testing

Ran the existing test suite, and all tests pass with the applied changes.
Verified that the ResourceWarning is no longer raised at the end of Python tests.

Please review and consider merging this pull request to resolve the socket warning issue.

thanks!
wanna share more about graphmix?? it looks very interesting.

For sure! Its from one of my PhD projects and is for designing protocols that account for things like serial dilutions, container dead volumes, pipette min/max transfer volumes, etc. As the name implies, it uses graphs to describe solutions, and it can be used to solve the composition of anything in a network of fluid transfers. I use Pint everywhere to avoid naked numbers.
I'm also using graphs to map transfers with liquid handlers so that I can say, for example, "I want concentrations X, Y, and Z of stock solution A diluted with solution B, and to have the final volume of everything be 100 µL," then it will solve the transfer volumes and initial volumes of my stock and diluent.
I'm still moving and improving it from a private repo, so the graph transfer mapping isn't in graphmix yet, but should be by the end of the week!
This is what it looks like when it solves the volumes for the standard curve from the BCA assay protocol, which was my original motivation:

The most concentrated stock is in 0:A1, the diluent is 0:A2, concentrations decrease from 0:A4 (red) through 0:A12, (blue) and everything ends up being 100 µL
The graph was generated with just:
BCA_STANDARD_CURVE = (
    StandardCurveStep(ref="A", factor=1),
    StandardCurveStep(ref="B", factor=0.75),
    StandardCurveStep(ref="C", factor=0.5),
    StandardCurveStep(ref="D", source="B", factor=0.5),
    StandardCurveStep(ref="E", source="C", factor=0.5),
    StandardCurveStep(ref="F", source="E", factor=0.5),
    StandardCurveStep(ref="G", source="F", factor=0.5),
    StandardCurveStep(ref="H", source="G", factor=0.5),
    StandardCurveStep(ref="I", factor=0),
)

G = graph.standard_curve(
    G=G,
    stock=source,
    diluent=diluent,
    final_volume=Q_("100 µL"),
    grid="0",
    positions=source.location.pos_increment,
    steps=BCA_STANDARD_CURVE,
)

graph.solve(G)

I have a high level AbstractProtocolBuilder base class that uses the builder pattern, then use that to create more crazy things like this:

which

makes a product
samples it for different assays
makes standard curves for the assays
prepare the product that was made for the assays

Thanks for your work on PyLabRobot, it's a perfect fit for what I've been working on!

Wow that's really cool & this would be super useful to integrate with PLR/another automated liquid handling system! Perhaps a premature question: is there any ordering to the edges or is that found using a separate algorithm? I look forward to you open-sourcing and developing it more :)

Great question! Since I'm using directed acyclic graphs, I'm just using topological sorting to order the edges. Then, I group by source node, and will assign a priority so that aqueous buffers and larger volumes are transferred first when the sources are at the same topological level. I'm also doing binning so that if 50 µL of something needs to go to 4 places, it will pickup 200 µL and distribute instead of 4 separate 50 µL transfers.
We can definitely find a way to integrate everything! I'll share on your forum once I get everything moved over if that's alright. I have a few more related projects that I am going to open source and publish papers on as well.
Thank you!


Add a License to project

Hello @shiviboi360, Just wanted add License to this project.

So, we added MIT License.


torch 2.3.x support

Currently autoawq and autoawq_kernels seems to be not compatible for pytorch 2.3.0:
Python 3.8.16 (default, Mar  2 2023, 03:21:46)
[GCC 11.2.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> import awq_ext
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /python3.8/site-packages/awq_ext.cpython-38-x86_64-linux-gnu.so: undefined symbol: _ZN3c104cuda9SetDeviceEi
>>>

One can repro by installing autoawq, autoawq_ext and torch 2.3.0 to get that error
cc @casper-hansen

This is a pytorch-related issue. You are installing wheels that are built with 2.2.0 and trying with torch 2.3.0. To fix this, you need to build from source or wait until AutoAWQ kernels are updated to 2.3.0.

+1 for this feature

New kernels should solve this, right?

@BenjaminBossan yes. I am building new kernels now and pushing an updated version to PyPi. Sorry for the delay - I plan to be faster at updating when new torch version is out.


feat: use grpc for internal call

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

GitHub release
v0.11.0
v0.11.0

Your semantic-release bot :package::rocket:


re-write weather module for toolkitem

http://www.it610.com/article/1697152.htm
http://cj.weather.com.cn/support/Detail.aspx?id=51837fba1b35fe0f8411b6df

https://developer.yahoo.com/weather/documentation.html


⚠ ClamAV has degraded performance

In e7576b2, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 441 ms

Resolved: ClamAV performance has improved in 7677331.