New Emqx gets OOMKilled immediately after deployment

Describe the bug
A clear and concise description of what the bug is.
I installed the cert-manager, then operator, then applied getting started yaml from docs.
The pods immediately fails saying OOMKilled, no logs.
I have tried other example deployment files, same issue with this file
Am I making some mistake ?
I have tried giving it more resources like this, but same issue
apiVersion: apps.emqx.io/v2beta1
kind: EMQX
metadata:
  name: emqx
spec:
  image: emqx:5
  coreTemplate:
    spec:
      resources:
        requests:
          cpu: 1
          memory: 512Mi
        limits:
          cpu: 1
          memory: 1024Mi

To Reproduce
Steps to reproduce the behavior:
Install operator using helm version : 2.2.23
And after wait to get conditions met from operator.
Then apply this
apiVersion: apps.emqx.io/v2beta1
kind: EMQX
metadata:
   name: emqx
spec:
   image: emqx:5

Expected behavior
The pods should run and cluster start
Anything else we need to know?:
enqx operator logs
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a mutating webhook","GVK":"apps.emqx.io/v1beta4, Kind=EmqxPlugin","path":"/mutate-apps-emqx-io-v1beta4-emqxplugin"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/mutate-apps-emqx-io-v1beta4-emqxplugin"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a validating webhook","GVK":"apps.emqx.io/v1beta4, Kind=EmqxPlugin","path":"/validate-apps-emqx-io-v1beta4-emqxplugin"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/validate-apps-emqx-io-v1beta4-emqxplugin"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/convert"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Conversion webhook enabled","GVK":"apps.emqx.io/v1beta4, Kind=EmqxPlugin"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a mutating webhook","GVK":"apps.emqx.io/v1beta4, Kind=EmqxBroker","path":"/mutate-apps-emqx-io-v1beta4-emqxbroker"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/mutate-apps-emqx-io-v1beta4-emqxbroker"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a validating webhook","GVK":"apps.emqx.io/v1beta4, Kind=EmqxBroker","path":"/validate-apps-emqx-io-v1beta4-emqxbroker"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/validate-apps-emqx-io-v1beta4-emqxbroker"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Conversion webhook enabled","GVK":"apps.emqx.io/v1beta4, Kind=EmqxBroker"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a mutating webhook","GVK":"apps.emqx.io/v1beta4, Kind=EmqxEnterprise","path":"/mutate-apps-emqx-io-v1beta4-emqxenterprise"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/mutate-apps-emqx-io-v1beta4-emqxenterprise"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a validating webhook","GVK":"apps.emqx.io/v1beta4, Kind=EmqxEnterprise","path":"/validate-apps-emqx-io-v1beta4-emqxenterprise"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/validate-apps-emqx-io-v1beta4-emqxenterprise"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Conversion webhook enabled","GVK":"apps.emqx.io/v1beta4, Kind=EmqxEnterprise"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"skip registering a mutating webhook, object does not implement admission.Defaulter or WithDefaulter wasn't called","GVK":"apps.emqx.io/v2beta1, Kind=Rebalance"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Registering a validating webhook","GVK":"apps.emqx.io/v2beta1, Kind=Rebalance","path":"/validate-apps-emqx-io-v2beta1-rebalance"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Registering webhook","path":"/validate-apps-emqx-io-v2beta1-rebalance"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.builder","msg":"Conversion webhook enabled","GVK":"apps.emqx.io/v2beta1, Kind=Rebalance"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"setup","msg":"starting manager"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.metrics","msg":"Starting metrics server"}
{"level":"info","ts":"2024-06-10T07:08:46Z","msg":"starting server","kind":"health probe","addr":"[::]:8081"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.metrics","msg":"Serving metrics server","bindAddress":":8080","secure":false}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Starting webhook server"}
I0610 07:08:46.566017       1 leaderelection.go:250] attempting to acquire leader lease emqx-operator-system/19fd6fcc.emqx.io...
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.certwatcher","msg":"Updated current TLS certificate"}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.webhook","msg":"Serving webhook server","host":"","port":9443}
{"level":"info","ts":"2024-06-10T07:08:46Z","logger":"controller-runtime.certwatcher","msg":"Starting certificate watcher"}
I0610 07:09:18.210702       1 leaderelection.go:260] successfully acquired lease emqx-operator-system/19fd6fcc.emqx.io
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting EventSource","controller":"emqxplugin","controllerGroup":"apps.emqx.io","controllerKind":"EmqxPlugin","source":"kind source: *v1beta4.EmqxPlugin"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting Controller","controller":"emqxplugin","controllerGroup":"apps.emqx.io","controllerKind":"EmqxPlugin"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting EventSource","controller":"emqxenterprise","controllerGroup":"apps.emqx.io","controllerKind":"EmqxEnterprise","source":"kind source: *v1beta4.EmqxEnterprise"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting Controller","controller":"emqxenterprise","controllerGroup":"apps.emqx.io","controllerKind":"EmqxEnterprise"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting EventSource","controller":"rebalance","controllerGroup":"apps.emqx.io","controllerKind":"Rebalance","source":"kind source: *v2beta1.Rebalance"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting Controller","controller":"rebalance","controllerGroup":"apps.emqx.io","controllerKind":"Rebalance"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting EventSource","controller":"emqx","controllerGroup":"apps.emqx.io","controllerKind":"EMQX","source":"kind source: *v2beta1.EMQX"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting Controller","controller":"emqx","controllerGroup":"apps.emqx.io","controllerKind":"EMQX"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting EventSource","controller":"emqxbroker","controllerGroup":"apps.emqx.io","controllerKind":"EmqxBroker","source":"kind source: *v1beta4.EmqxBroker"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting Controller","controller":"emqxbroker","controllerGroup":"apps.emqx.io","controllerKind":"EmqxBroker"}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting workers","controller":"emqxplugin","controllerGroup":"apps.emqx.io","controllerKind":"EmqxPlugin","worker count":1}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting workers","controller":"emqxbroker","controllerGroup":"apps.emqx.io","controllerKind":"EmqxBroker","worker count":1}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting workers","controller":"rebalance","controllerGroup":"apps.emqx.io","controllerKind":"Rebalance","worker count":1}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting workers","controller":"emqxenterprise","controllerGroup":"apps.emqx.io","controllerKind":"EmqxEnterprise","worker count":1}
{"level":"info","ts":"2024-06-10T07:09:18Z","msg":"Starting workers","controller":"emqx","controllerGroup":"apps.emqx.io","controllerKind":"EMQX","worker count":1}
{"level":"info","ts":"2024-06-10T07:23:53Z","msg":"got different pod template for EMQX core nodes, will create new statefulSet","controller":"emqx","controllerGroup":"apps.emqx.io","controllerKind":"EMQX","EMQX":{"name":"emqx","namespace":"emqx"},"namespace":"emqx","name":"emqx","reconcileID":"944ac40c-c12b-4f43-8ca8-efaa01c98c60","statefulSet":{"name":"emqx-core-6bd465679f","namespace":"emqx"},"patch":"{should create new StatefulSet}"}
{"level":"info","ts":"2024-06-10T07:23:54Z","logger":"KubeAPIWarningLogger","msg":"unknown field \"spec.coreTemplate.metadata.creationTimestamp\""}

Environment details::

Kubernetes version: 1.29
Cloud-provider/provisioner: aws
emqx-operator version: 2.2.23
Install method: helm chart

So strange, could you please check the failed pod and share it , just running kubectl get pod $name -o json and kubectl logs -p $name
And please make sure your node have enough resource

Did it just now again

Get pod output
kubectl get pod $name -o json
{
    "apiVersion": "v1",
    "items": [
        {
            "apiVersion": "v1",
            "kind": "Pod",
            "metadata": {
                "creationTimestamp": "2024-06-11T03:58:41Z",
                "generateName": "emqx-core-75ff7c75f9-",
                "labels": {
                    "apps.emqx.io/db-role": "core",
                    "apps.emqx.io/instance": "emqx",
                    "apps.emqx.io/managed-by": "emqx-operator",
                    "apps.emqx.io/pod-template-hash": "75ff7c75f9",
                    "apps.kubernetes.io/pod-index": "0",
                    "controller-revision-hash": "emqx-core-75ff7c75f9-df4bcf689",
                    "statefulset.kubernetes.io/pod-name": "emqx-core-75ff7c75f9-0"
                },
                "name": "emqx-core-75ff7c75f9-0",
                "namespace": "emqx",
                "ownerReferences": [
                    {
                        "apiVersion": "apps/v1",
                        "blockOwnerDeletion": true,
                        "controller": true,
                        "kind": "StatefulSet",
                        "name": "emqx-core-75ff7c75f9",
                        "uid": "19197aa0-ba43-4a3b-ab12-8c203107ff1f"
                    }
                ],
                "resourceVersion": "32867086",
                "uid": "63b85614-e6f1-4b46-8006-44bf1cf0dcb3"
            },
            "spec": {
                "containers": [
                    {
                        "env": [
                            {
                                "name": "EMQX_DASHBOARD__LISTENERS__HTTP__BIND",
                                "value": "18083"
                            },
                            {
                                "name": "POD_NAME",
                                "valueFrom": {
                                    "fieldRef": {
                                        "apiVersion": "v1",
                                        "fieldPath": "metadata.name"
                                    }
                                }
                            },
                            {
                                "name": "EMQX_CLUSTER__DISCOVERY_STRATEGY",
                                "value": "dns"
                            },
                            {
                                "name": "EMQX_CLUSTER__DNS__RECORD_TYPE",
                                "value": "srv"
                            },
                            {
                                "name": "EMQX_CLUSTER__DNS__NAME",
                                "value": "emqx-headless.emqx.svc.cluster.local"
                            },
                            {
                                "name": "EMQX_HOST",
                                "value": "$(POD_NAME).$(EMQX_CLUSTER__DNS__NAME)"
                            },
                            {
                                "name": "EMQX_NODE__DATA_DIR",
                                "value": "data"
                            },
                            {
                                "name": "EMQX_NODE__ROLE",
                                "value": "core"
                            },
                            {
                                "name": "EMQX_NODE__COOKIE",
                                "valueFrom": {
                                    "secretKeyRef": {
                                        "key": "node_cookie",
                                        "name": "emqx-node-cookie"
                                    }
                                }
                            },
                            {
                                "name": "EMQX_API_KEY__BOOTSTRAP_FILE",
                                "value": "\"/opt/emqx/data/bootstrap_api_key\""
                            }
                        ],
                        "image": "emqx:5",
                        "imagePullPolicy": "IfNotPresent",
                        "livenessProbe": {
                            "failureThreshold": 3,
                            "httpGet": {
                                "path": "/status",
                                "port": "dashboard",
                                "scheme": "HTTP"
                            },
                            "initialDelaySeconds": 60,
                            "periodSeconds": 30,
                            "successThreshold": 1,
                            "timeoutSeconds": 1
                        },
                        "name": "emqx",
                        "ports": [
                            {
                                "containerPort": 18083,
                                "name": "dashboard",
                                "protocol": "TCP"
                            }
                        ],
                        "readinessProbe": {
                            "failureThreshold": 12,
                            "httpGet": {
                                "path": "/status",
                                "port": "dashboard",
                                "scheme": "HTTP"
                            },
                            "initialDelaySeconds": 10,
                            "periodSeconds": 5,
                            "successThreshold": 1,
                            "timeoutSeconds": 1
                        },
                        "resources": {
                            "limits": {
                                "cpu": "1",
                                "memory": "1Gi"
                            },
                            "requests": {
                                "cpu": "1",
                                "memory": "512Mi"
                            }
                        },
                        "securityContext": {
                            "runAsGroup": 1000,
                            "runAsNonRoot": true,
                            "runAsUser": 1000
                        },
                        "terminationMessagePath": "/dev/termination-log",
                        "terminationMessagePolicy": "File",
                        "volumeMounts": [
                            {
                                "mountPath": "/opt/emqx/data/bootstrap_api_key",
                                "name": "bootstrap-api-key",
                                "readOnly": true,
                                "subPath": "bootstrap_api_key"
                            },
                            {
                                "mountPath": "/opt/emqx/etc/emqx.conf",
                                "name": "bootstrap-config",
                                "readOnly": true,
                                "subPath": "emqx.conf"
                            },
                            {
                                "mountPath": "/opt/emqx/log",
                                "name": "emqx-core-log"
                            },
                            {
                                "mountPath": "/opt/emqx/data",
                                "name": "emqx-core-data"
                            },
                            {
                                "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
                                "name": "kube-api-access-5lp9j",
                                "readOnly": true
                            }
                        ]
                    }
                ],
                "dnsPolicy": "ClusterFirst",
                "enableServiceLinks": true,
                "hostname": "emqx-core-75ff7c75f9-0",
                "nodeName": "ip-10-16-253-98.ec2.internal",
                "preemptionPolicy": "PreemptLowerPriority",
                "priority": 0,
                "readinessGates": [
                    {
                        "conditionType": "apps.emqx.io/on-serving"
                    }
                ],
                "restartPolicy": "Always",
                "schedulerName": "default-scheduler",
                "securityContext": {
                    "fsGroup": 1000,
                    "fsGroupChangePolicy": "Always",
                    "runAsGroup": 1000,
                    "runAsUser": 1000,
                    "supplementalGroups": [
                        1000
                    ]
                },
                "serviceAccount": "default",
                "serviceAccountName": "default",
                "subdomain": "emqx-headless",
                "terminationGracePeriodSeconds": 30,
                "tolerations": [
                    {
                        "effect": "NoExecute",
                        "key": "node.kubernetes.io/not-ready",
                        "operator": "Exists",
                        "tolerationSeconds": 300
                    },
                    {
                        "effect": "NoExecute",
                        "key": "node.kubernetes.io/unreachable",
                        "operator": "Exists",
                        "tolerationSeconds": 300
                    }
                ],
                "volumes": [
                    {
                        "name": "emqx-core-data",
                        "persistentVolumeClaim": {
                            "claimName": "emqx-core-data-emqx-core-75ff7c75f9-0"
                        }
                    },
                    {
                        "name": "bootstrap-api-key",
                        "secret": {
                            "defaultMode": 420,
                            "secretName": "emqx-bootstrap-api-key"
                        }
                    },
                    {
                        "configMap": {
                            "defaultMode": 420,
                            "name": "emqx-configs"
                        },
                        "name": "bootstrap-config"
                    },
                    {
                        "emptyDir": {},
                        "name": "emqx-core-log"
                    },
                    {
                        "name": "kube-api-access-5lp9j",
                        "projected": {
                            "defaultMode": 420,
                            "sources": [
                                {
                                    "serviceAccountToken": {
                                        "expirationSeconds": 3607,
                                        "path": "token"
                                    }
                                },
                                {
                                    "configMap": {
                                        "items": [
                                            {
                                                "key": "ca.crt",
                                                "path": "ca.crt"
                                            }
                                        ],
                                        "name": "kube-root-ca.crt"
                                    }
                                },
                                {
                                    "downwardAPI": {
                                        "items": [
                                            {
                                                "fieldRef": {
                                                    "apiVersion": "v1",
                                                    "fieldPath": "metadata.namespace"
                                                },
                                                "path": "namespace"
                                            }
                                        ]
                                    }
                                }
                            ]
                        }
                    }
                ]
            },
            "status": {
                "conditions": [
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": null,
                        "status": "",
                        "type": "apps.emqx.io/on-serving"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:45Z",
                        "status": "True",
                        "type": "PodReadyToStartContainers"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "status": "True",
                        "type": "Initialized"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "message": "containers with unready status: [emqx]",
                        "reason": "ContainersNotReady",
                        "status": "False",
                        "type": "Ready"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "message": "containers with unready status: [emqx]",
                        "reason": "ContainersNotReady",
                        "status": "False",
                        "type": "ContainersReady"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "status": "True",
                        "type": "PodScheduled"
                    }
                ],
                "containerStatuses": [
                    {
                        "containerID": "containerd://48de18c9bb87de65ae106acc273547ae180526e876f3fef214a8b04e6ed219b3",
                        "image": "docker.io/library/emqx:5",
                        "imageID": "docker.io/library/emqx@sha256:4750557065e94e53e0ec96f9a804c1bb4bc3c6001a5ef517f9b873eea886e0ae",
                        "lastState": {
                            "terminated": {
                                "containerID": "containerd://48de18c9bb87de65ae106acc273547ae180526e876f3fef214a8b04e6ed219b3",
                                "exitCode": 137,
                                "finishedAt": "2024-06-11T03:59:02Z",
                                "reason": "OOMKilled",
                                "startedAt": "2024-06-11T03:59:01Z"
                            }
                        },
                        "name": "emqx",
                        "ready": false,
                        "restartCount": 2,
                        "started": false,
                        "state": {
                            "waiting": {
                                "message": "back-off 20s restarting failed container=emqx pod=emqx-core-75ff7c75f9-0_emqx(63b85614-e6f1-4b46-8006-44bf1cf0dcb3)",
                                "reason": "CrashLoopBackOff"
                            }
                        }
                    }
                ],
                "hostIP": "<IP_ADDRESS>",
                "hostIPs": [
                    {
                        "ip": "<IP_ADDRESS>"
                    }
                ],
                "phase": "Running",
                "podIP": "<IP_ADDRESS>",
                "podIPs": [
                    {
                        "ip": "<IP_ADDRESS>"
                    }
                ],
                "qosClass": "Burstable",
                "startTime": "2024-06-11T03:58:41Z"
            }
        },
        {
            "apiVersion": "v1",
            "kind": "Pod",
            "metadata": {
                "creationTimestamp": "2024-06-11T03:58:41Z",
                "generateName": "emqx-core-75ff7c75f9-",
                "labels": {
                    "apps.emqx.io/db-role": "core",
                    "apps.emqx.io/instance": "emqx",
                    "apps.emqx.io/managed-by": "emqx-operator",
                    "apps.emqx.io/pod-template-hash": "75ff7c75f9",
                    "apps.kubernetes.io/pod-index": "1",
                    "controller-revision-hash": "emqx-core-75ff7c75f9-df4bcf689",
                    "statefulset.kubernetes.io/pod-name": "emqx-core-75ff7c75f9-1"
                },
                "name": "emqx-core-75ff7c75f9-1",
                "namespace": "emqx",
                "ownerReferences": [
                    {
                        "apiVersion": "apps/v1",
                        "blockOwnerDeletion": true,
                        "controller": true,
                        "kind": "StatefulSet",
                        "name": "emqx-core-75ff7c75f9",
                        "uid": "19197aa0-ba43-4a3b-ab12-8c203107ff1f"
                    }
                ],
                "resourceVersion": "32867077",
                "uid": "7d5d46db-4937-49b8-87b7-0130fe4f614b"
            },
            "spec": {
                "containers": [
                    {
                        "env": [
                            {
                                "name": "EMQX_DASHBOARD__LISTENERS__HTTP__BIND",
                                "value": "18083"
                            },
                            {
                                "name": "POD_NAME",
                                "valueFrom": {
                                    "fieldRef": {
                                        "apiVersion": "v1",
                                        "fieldPath": "metadata.name"
                                    }
                                }
                            },
                            {
                                "name": "EMQX_CLUSTER__DISCOVERY_STRATEGY",
                                "value": "dns"
                            },
                            {
                                "name": "EMQX_CLUSTER__DNS__RECORD_TYPE",
                                "value": "srv"
                            },
                            {
                                "name": "EMQX_CLUSTER__DNS__NAME",
                                "value": "emqx-headless.emqx.svc.cluster.local"
                            },
                            {
                                "name": "EMQX_HOST",
                                "value": "$(POD_NAME).$(EMQX_CLUSTER__DNS__NAME)"
                            },
                            {
                                "name": "EMQX_NODE__DATA_DIR",
                                "value": "data"
                            },
                            {
                                "name": "EMQX_NODE__ROLE",
                                "value": "core"
                            },
                            {
                                "name": "EMQX_NODE__COOKIE",
                                "valueFrom": {
                                    "secretKeyRef": {
                                        "key": "node_cookie",
                                        "name": "emqx-node-cookie"
                                    }
                                }
                            },
                            {
                                "name": "EMQX_API_KEY__BOOTSTRAP_FILE",
                                "value": "\"/opt/emqx/data/bootstrap_api_key\""
                            }
                        ],
                        "image": "emqx:5",
                        "imagePullPolicy": "IfNotPresent",
                        "livenessProbe": {
                            "failureThreshold": 3,
                            "httpGet": {
                                "path": "/status",
                                "port": "dashboard",
                                "scheme": "HTTP"
                            },
                            "initialDelaySeconds": 60,
                            "periodSeconds": 30,
                            "successThreshold": 1,
                            "timeoutSeconds": 1
                        },
                        "name": "emqx",
                        "ports": [
                            {
                                "containerPort": 18083,
                                "name": "dashboard",
                                "protocol": "TCP"
                            }
                        ],
                        "readinessProbe": {
                            "failureThreshold": 12,
                            "httpGet": {
                                "path": "/status",
                                "port": "dashboard",
                                "scheme": "HTTP"
                            },
                            "initialDelaySeconds": 10,
                            "periodSeconds": 5,
                            "successThreshold": 1,
                            "timeoutSeconds": 1
                        },
                        "resources": {
                            "limits": {
                                "cpu": "1",
                                "memory": "1Gi"
                            },
                            "requests": {
                                "cpu": "1",
                                "memory": "512Mi"
                            }
                        },
                        "securityContext": {
                            "runAsGroup": 1000,
                            "runAsNonRoot": true,
                            "runAsUser": 1000
                        },
                        "terminationMessagePath": "/dev/termination-log",
                        "terminationMessagePolicy": "File",
                        "volumeMounts": [
                            {
                                "mountPath": "/opt/emqx/data/bootstrap_api_key",
                                "name": "bootstrap-api-key",
                                "readOnly": true,
                                "subPath": "bootstrap_api_key"
                            },
                            {
                                "mountPath": "/opt/emqx/etc/emqx.conf",
                                "name": "bootstrap-config",
                                "readOnly": true,
                                "subPath": "emqx.conf"
                            },
                            {
                                "mountPath": "/opt/emqx/log",
                                "name": "emqx-core-log"
                            },
                            {
                                "mountPath": "/opt/emqx/data",
                                "name": "emqx-core-data"
                            },
                            {
                                "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount",
                                "name": "kube-api-access-j6xpw",
                                "readOnly": true
                            }
                        ]
                    }
                ],
                "dnsPolicy": "ClusterFirst",
                "enableServiceLinks": true,
                "hostname": "emqx-core-75ff7c75f9-1",
                "nodeName": "ip-10-16-253-98.ec2.internal",
                "preemptionPolicy": "PreemptLowerPriority",
                "priority": 0,
                "readinessGates": [
                    {
                        "conditionType": "apps.emqx.io/on-serving"
                    }
                ],
                "restartPolicy": "Always",
                "schedulerName": "default-scheduler",
                "securityContext": {
                    "fsGroup": 1000,
                    "fsGroupChangePolicy": "Always",
                    "runAsGroup": 1000,
                    "runAsUser": 1000,
                    "supplementalGroups": [
                        1000
                    ]
                },
                "serviceAccount": "default",
                "serviceAccountName": "default",
                "subdomain": "emqx-headless",
                "terminationGracePeriodSeconds": 30,
                "tolerations": [
                    {
                        "effect": "NoExecute",
                        "key": "node.kubernetes.io/not-ready",
                        "operator": "Exists",
                        "tolerationSeconds": 300
                    },
                    {
                        "effect": "NoExecute",
                        "key": "node.kubernetes.io/unreachable",
                        "operator": "Exists",
                        "tolerationSeconds": 300
                    }
                ],
                "volumes": [
                    {
                        "name": "emqx-core-data",
                        "persistentVolumeClaim": {
                            "claimName": "emqx-core-data-emqx-core-75ff7c75f9-1"
                        }
                    },
                    {
                        "name": "bootstrap-api-key",
                        "secret": {
                            "defaultMode": 420,
                            "secretName": "emqx-bootstrap-api-key"
                        }
                    },
                    {
                        "configMap": {
                            "defaultMode": 420,
                            "name": "emqx-configs"
                        },
                        "name": "bootstrap-config"
                    },
                    {
                        "emptyDir": {},
                        "name": "emqx-core-log"
                    },
                    {
                        "name": "kube-api-access-j6xpw",
                        "projected": {
                            "defaultMode": 420,
                            "sources": [
                                {
                                    "serviceAccountToken": {
                                        "expirationSeconds": 3607,
                                        "path": "token"
                                    }
                                },
                                {
                                    "configMap": {
                                        "items": [
                                            {
                                                "key": "ca.crt",
                                                "path": "ca.crt"
                                            }
                                        ],
                                        "name": "kube-root-ca.crt"
                                    }
                                },
                                {
                                    "downwardAPI": {
                                        "items": [
                                            {
                                                "fieldRef": {
                                                    "apiVersion": "v1",
                                                    "fieldPath": "metadata.namespace"
                                                },
                                                "path": "namespace"
                                            }
                                        ]
                                    }
                                }
                            ]
                        }
                    }
                ]
            },
            "status": {
                "conditions": [
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": null,
                        "status": "",
                        "type": "apps.emqx.io/on-serving"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:45Z",
                        "status": "True",
                        "type": "PodReadyToStartContainers"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "status": "True",
                        "type": "Initialized"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "message": "containers with unready status: [emqx]",
                        "reason": "ContainersNotReady",
                        "status": "False",
                        "type": "Ready"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "message": "containers with unready status: [emqx]",
                        "reason": "ContainersNotReady",
                        "status": "False",
                        "type": "ContainersReady"
                    },
                    {
                        "lastProbeTime": null,
                        "lastTransitionTime": "2024-06-11T03:58:41Z",
                        "status": "True",
                        "type": "PodScheduled"
                    }
                ],
                "containerStatuses": [
                    {
                        "containerID": "containerd://082125f05b7dca038e6a1910f72366e5852609065f415a82861ee38fad656dea",
                        "image": "docker.io/library/emqx:5",
                        "imageID": "docker.io/library/emqx@sha256:4750557065e94e53e0ec96f9a804c1bb4bc3c6001a5ef517f9b873eea886e0ae",
                        "lastState": {
                            "terminated": {
                                "containerID": "containerd://082125f05b7dca038e6a1910f72366e5852609065f415a82861ee38fad656dea",
                                "exitCode": 137,
                                "finishedAt": "2024-06-11T03:59:00Z",
                                "reason": "OOMKilled",
                                "startedAt": "2024-06-11T03:59:00Z"
                            }
                        },
                        "name": "emqx",
                        "ready": false,
                        "restartCount": 2,
                        "started": false,
                        "state": {
                            "waiting": {
                                "message": "back-off 20s restarting failed container=emqx pod=emqx-core-75ff7c75f9-1_emqx(7d5d46db-4937-49b8-87b7-0130fe4f614b)",
                                "reason": "CrashLoopBackOff"
                            }
                        }
                    }
                ],
                "hostIP": "<IP_ADDRESS>",
                "hostIPs": [
                    {
                        "ip": "<IP_ADDRESS>"
                    }
                ],
                "phase": "Running",
                "podIP": "<IP_ADDRESS>",
                "podIPs": [
                    {
                        "ip": "<IP_ADDRESS>"
                    }
                ],
                "qosClass": "Burstable",
                "startTime": "2024-06-11T03:58:41Z"
            }
        }
    ],
    "kind": "List",
    "metadata": {
        "resourceVersion": ""
    }
}

yea, if I have some logs it would have been great, that's why it is very strange.
I tried chaging log level to debug but no results.
Also changed increased the limit to 1024Mi.
I am able to run the docker image in my laptop and when I monitored it's resource consumption it didn't exceed 250mb.

stats of the node where the pod is scheduled

I'm sorry, I have no idea.
Cloud you please cancel the resource limit of emqx, and retry, let's watch how many memory does it use, and maybe we can get some log of emqx. I think it will be helpful for us.

Hi, It worked when I removed limit, but the memory consumption is low

to test this theory I put back the limit and it started crashing again

This is the file I applied, hopefully this help you in figuring this out.
Normally when the limits is lower than requests it won't get applied, maybe the default is too low.
apiVersion: apps.emqx.io/v2beta1
kind: EMQX
metadata:
  name: emqx
spec:
  image: emqx:5
  config:
    data: |
      log.console.level = debug
  coreTemplate:
    spec:
      resources:
        requests:
          cpu: 2
          memory: 1024Mi
        limits:
          cpu: 2
          memory: 1024Mi
      ## EMQX custom resources do not support updating this field at runtime
      volumeClaimTemplates:
        ## More content: https://docs.aws.amazon.com/eks/latest/userguide/storage-classes.html
        ## Please manage the Amazon EBS CSI driver as an Amazon EKS add-on.
        ## For more documentation please refer to: https://docs.aws.amazon.com/zh_cn/eks/latest/userguide/managing-ebs-csi.html
        storageClassName: gp2
        resources:
          requests:
            storage: 10Gi
        accessModes:
          - ReadWriteOnce
  dashboardServiceTemplate:
    metadata:
      ## More content: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/
      annotations:
        ## Specifies whether the NLB is Internet-facing or internal. If not specified, defaults to internal.
        service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
        ## Specify the availability zone to which the NLB will route traffic. Specify at least one subnet, either subnetID or subnetName (subnet name label) can be used.
        service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-xxx1,subnet-xxx2
    spec:
      type: LoadBalancer
      ## More content: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/nlb/
      loadBalancerClass: service.k8s.aws/nlb
  listenersServiceTemplate:
    metadata:
      ## More content: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/annotations/
      annotations:
        ## Specifies whether the NLB is Internet-facing or internal. If not specified, defaults to internal.
        service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
        ## Specify the availability zone to which the NLB will route traffic. Specify at least one subnet, either subnetID or subnetName (subnet name label) can be used.
        service.beta.kubernetes.io/aws-load-balancer-subnets: subnet-xxx1,subnet-xxx2
    spec:
      type: LoadBalancer
      ## More content: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/guide/service/nlb/
      loadBalancerClass: service.k8s.aws/nlb

@zmstone @id Do we have any suggestion for emqx memory, could you please take a look

Regular docker image starts just fine with this limits
docker run -d --name emqx --memory=512m --kernel-memory=1024m --cpus=1 emqx:5

Perhaps there is a memory spike when operator applies config via API? Can we get core dump to see what exactly caused it?

I am not sure how to take a core dump, if there is some commands that I can run, will replicate and send it.


get_ssm_by_regions() is duplicating variants, and assigning them to the incorrect regions

Running get_ssm_by_regions(grch37_ashm_regions) yields the following dataframe:

For some reason, this function is only returning variants upstream of MYC, and assigning them to (seemingly) ALL regions provided

@mattssca already fixed this issue. Here's how I run it and it works on my branch. Waiting for that PR to be merged, unfortunately.
all_dlbcl_genome_ashm = get_ssm_by_regions(regions_bed=regions_bed,seq_type="genome",streamlined = F)

The PR with a fix for this has now been merged into Master


Codify shared responsibility model 'lines' for the NASA VEDA Hubs

Thanks to efforts from me and @colliand, we've been able to get more resources from Development Seed for working with the NASA VEDA, GHG and ESDIS hubs. They're a very ideologically aligned organization, but focused more on development rather than infrastructure (https://github.com/2i2c-org/leads/issues/260 has more information).
From the perspective of 2i2c engineering, this should result in a net decrease in the amount of work we have to do for these hubs. In particular, I think it would:

Establish a 'first level of support' that isn't us. So fewer support requests coming our way.
Move responsibility for image management completely away from us.
Provide more engineering (and review) resources for upstream Jupyter development in various ways. Note that this doesn't commit 2i2c engineering resources to anything.
They would also be able to help handle requests in many ways. In terms of https://github.com/2i2c-org/meta/issues/953#issuecomment-2030777639, a lot of 'feature enablement' or 'config change' will instead turn into 'community config change review'. https://github.com/2i2c-org/infrastructure/issues/3735 for example would be something off our hands.

They love the 2i2c shared responsibility model. This issue tracks clarifying these, so we know who is exactly responsible for what with the now increased capacity.

There's now an official "NASA VEDA JupyterHub team lead", which happens to be @batpad (from Development Seed). He's contributed to kubespawner before, has a lot of tech lead expertise, and also is my very long time friend, initially via the open source world.


Font display problem

Version confirmation

[X] Confirm

Following prerequisites

[X] Confirm

Neovim version
NVIM v0.9.2
Branch info
main (Default/Latest)
Minimal (user) folder structure required to reproduce the issue
No modified

Minimal config with steps on how to reproduce the issue
I am running nvim on WSL, and the font is set to JetBrainsMono Nerd Font, but some fonts are not fully displayed in nvim, as shown in the figure below:
This is in Vim

This is in Nvim:

In nvim, there is a problem with the display of ‘0’
Expected behavior
How to slove it?
Additional information
No response

When I add (abcd at the end, the 0 can be displayed correctly, but there is another problem with d

it got nothing to do with nvim config, set your terminal font properly or use another terminal.

Could you please tell me what font you used?

I use jetbrains-nerd-fonts with wezterm.
u can check my wezterm config: https://github.com/CharlesChiuGit/dotfiles/tree/main/terminals/wezterm

u can use this plugin in our nvim config to display those error messages.
https://github.com/folke/trouble.nvim#commands

The above problem is solved only if I use italic font........

Are u using a font collection (which usually contains multiple variants such as Normal, Bold, Italic, BoldItalic, etc.) as the preferred font for ur terminal? Because if u only use a specific variant, ur terminal could reasonably assume that the containing glyphs all fit in a specific scaled "box", and using italics here (possibly "simulated" by ur terminal) would then lead to the problem you mentioned above.

The above problem is solved only if I use italic font........

Are u using a font collection (which usually contains multiple variants such as Normal, Bold, Italic, BoldItalic, etc.) as the preferred font for ur terminal? Because if u only use a specific variant, ur terminal could reasonably assume that the containing glyphs all fit in a specific scaled "box", and using italics here (possibly "simulated" by ur terminal) would then lead to the problem you mentioned above.

thank u very much!!  u say is right. I only have a specific variant of font installed.

I love SauceCodePro Nerd Font Mono, but some icons cannot be successfully displayed. It's so sad.

@yinghaoyu make sure your nerdfont is up-to-date, or u need https://github.com/loichyan/nerdfix


We create multiple service monitors of cert-manager

When installing the Prometheus-alerts chart, we create a service monitor for cert-manager. This is unnecessary since cert-manager creates on itself.
This also makes it such that Prometheus drops samples since we have two identical targets (except for the name).
Suggested solution
Delete the file helmfile/charts/prometheus-alerts/templates/cert-monitor.yaml
Acceptance criteria
When installing, the cluster should only have one service monitor for cert-manager.

False accusations, there's only one service monitor created

False accusations, there's only one service monitor created


[IE] Kunliang/add slice

Add Op Slice based on the openVINO backend. The DML backend is not implemented in this PR. The SlicesOptions will be supported soon.

The SliceOptions is supported. PTAL, @fujunwei .

Merge it.


install.sh: Add remote install support

Closes cdr/sshcode#185 and pretty much archives that repository.
See also #1991

Yea I think I'ma update all the docs/messages when installing remotely and modify fetch to fetch locally and then copy over ssh so that it works in closed off environments.

This got messy quickly, opening a follow up PR without --start and no support for hosts without internet which I think is fine for now.


[WIP] Add drag and drop ui

This pull request makes the following changes:

Call list can be reordered by drag & drop
Generate an ordered array of row ID's to send to endpoint

It relates to the following issue #s:

Fixes #520

@mchelen I merged this branch into my other track, it's looking good with hardcoded ids. Have some further issues to sort out before we declare victory, but this is so, so, so awesome.


groq support

hello,
groq.com also has a whisper api, and it also has a generous free tier. could you add support for it in your keyboard?
the effort should not be too bbig. I see you already support custom whisper host, the thing is groq's url contains "/openapi" before the normal openai api path (https://api.groq.com/openai/v1/audio/transcriptions), and entering that in the host field in settings crashes the app, probably since it does not expect an address in there, but just a host.
Thanks.

I'd like to investigate this issue further, but I cannot sign in to groq.com. Could you send me an API key for testing to my email-address, so that I can fix this issue? :)
<EMAIL_ADDRESS>

I sent it. Did you receive it?

Yes, thank you very much, I received it. However, I have been too busy the last few days adding other features that I haven't had the chance to look into it further yet. I will definitely take a look at it. :)

I have now had a closer look at groq's API and apparently they are using a different scheme than OpenAI. So unfortunately I can't support groq because the library is only orientated towards OpenAI.


Update changelog for release

Updated manually for now, as git-chglog removes manually added changelog content for v0.4.0.
An option would be to craft the template to contain those old entries: https://github.com/git-chglog/git-chglog/issues/55

Once this hits master, I will push the v0.4.1 tag to https://github.com/kubewarden/kubewarden-controller/pull/118/commits/ac9ded8f412c2a7224e3185e4861664a42c572ef.


Top item in list of themes hidden by site header

Home Assistant release (hass --version):
0.59.2
Python release (python3 --version):
3.5.3
Component/platform:
frontend
Description of problem:
In Configuration > General > Set a theme, if you have a large number of themes the top of the drop-down box is behind the header bar (see pic below). This obscures the top option of Backend-selected. This behaviour is apparent in Chrome 63 (Windows and Android), and Firefox 58. I can only select the top item in the list if I set my browser zoom to 80%.
Expected:
The theme selection drop-down list should be rendered on top of the site header.
Additional info:

This also affects dropdowns on the zwave configuration page

Ah, I realise this issue should probably have been raised in the home-assistant-polymer repo - sorry if this is the wrong place.
Chris

Hmm.. I'd already reported this and it was fixed once: home-assistant/home-assistant-polymer#475. Maybe the workaround isn't working around anymore?

Ah, I see, really sorry - I forgot to search the home-assistant-polymer issues even after I realised this was the wrong repo.
It does look like an open issue: https://github.com/PolymerElements/iron-fit-behavior/issues/80

I have noticed that when directed to the Home Assistant frontend the safari browser (android tablet) loses the top of the page under the tab strip. This 'sometimes' happens on Chrome on Win 10 too (rare) but what is a lot more common on Chrome is that the first two tabs are underlined instead of just the first

I mention this as it all seems to be banner related
Mutt


Support GlobPattern in DocumentFilter

in the VS Code API, DocumentFilter's pattern property is a GlobPattern (docs), which supports RelativePattern. but in the LSP only string is supported.
now that RelativePattern is part of the LSP, I propose that LSP's DocumentFilter.pattern also become a GlobPattern.
at the very least, it should be a Pattern, not just a string.

Implemented and documented for 3.18 release


Model/dataset matching in frontend UI

[ ] clickable links to models/datasets in the table

could start with https://react-data-table-component.netlify.app/?path=/docs/expandable-basic--basic

[ ] minimal 'model card' (showing description, installation, usage of the model) (e.g. as in #325)
[ ] filtering (e.g. show datasets compatible with a model)

For those with access to Turing sharepoint, this powerpoint explains the idea: https://thealanturininstitute.sharepoint.com/:p:/s/scivision/Ed1VOPuozxlNiuTAZWmG0zYB39l9cjgm0Kyx_8i_eimifw?e=uPkXSE

As a first step of this, I think it would be good to improve the model/dataset tables themselves:

Thumbnails for datasources: #204
[ ] Clickable links to GitHub repos
[ ] Expandable descriptions

PR inbound with some improvements!

PR inbound with some improvements!

Ok nice, I'll take a look in a bit! Images on slack look great

See #383


OIDC argument validation

The OIDC middleware does not validate if you set the ClientId or authority. It tries to fetch the metadata anyways, fails silently, and then generates redirects without any base uris.
We also need a better error if you fail to set the ClientSecret, but do enable one of the Code flows. Right now you'll get a 400/401 trying to redeem the code.

:+1: for requiring ClientId but :-1: for throwing an error if ClientSecret is not set, since one might want to use client authentication assertions instead of the good old client_id/client_secret couple.

962a74c4883e00da0666296c7c1751495f443ac0


set default quoting for CSV

seeing an uptick in errors on load dealing with double quoting in CSVs. adding that as a default.

solved in #22


[System] [Updates] An update is always available even after an install

It seems even after a fresh install an update is immediately available. No new build is available. Something is wrong with the mechanism for detecting a new update.  I think we should handle this if we have the bandwidth in this release.

@akarasulu this is not related to SS.
SS executes subutai update management -c command which checks updates on subos level,
SS just shows the output of this command

@ztimur Please look at this when you get back and create a new issue for the update CLI command.


SS malformed XLSX file: xfid attribute wrongly added to cellStyleXfs children

I'm using SS.
When saving a .xlsx document, the resulting file has an issue in styles.xml:
	<cellStyleXfs count="1"> 		<xf numFmtId="0" fontId="0" fillId="0" borderId="0" xfId="0"> 			<alignment horizontal="left" vertical="top"/> 		</xf> 	</cellStyleXfs>
I believe the attribute "xfId" shouldn't be there. Office can open the resulting file just fine (although if resaved, that attribute is removed), but other 3rd party programs/tools which are more strict about the markup complain about that additional attribute being there.
According to this, I don't think that attribute is needed there:
https://docs.microsoft.com/en-us/dotnet/api/documentformat.openxml.spreadsheet.cellstyleformats?view=openxml-2.8.1

I did remember I fix xfId issue according to the behavior of Microsoft Office. It used to be ignored when xfId=0 Would you please let me know what are other 3rd party programs/tools?


Correction of the link address

Closes: #XXX

Be noted that XXX is the issue ID

What is the purpose of the change

Add a description of the overall background and high level changes that this PR introduces

(Fixed a broken link in the docker architecture and removed an unnecessary image.
The path to the file devops-basic/topics/docker/README.md)

@all-contributors please add @zitaker as code


remove duplicate paragraph in "kubeadm Setup Tool Reference Guide"

Removed duplicate paragraph "Use Kubeadm with other CRI runtimes" (only one copy will remain in the doc)

This change is

I don't think any tech review is needed here, but LGTM :)
@chenopis This one is updated now.


Upgrade melange from 3.0.0-51 to 4.0.0-51

Going to wait for https://github.com/melange-re/melange-re.github.io to be updated before I change all the links from v3.0.0 to v4.0.0

[x] Upgrade melange from 3.0.0-51 to 4.0.0-51
[x] Update melange links from v3.0.0 to v4.0.0

Changes are pretty mechanical, merging


Route testing

Add More Route Testing & Repair Gulp Test Exit Issue. Also added test.scp file.

looks fine to me

Well done!


Questions: Can I use the Jetson Orin Nano as a controller?

HI,
I make a human following robot with Jetson Orin Nano and 4WD wave rover.
As I wrote on the title, I will use the Jetson Orin Nano as a controller.
So, I want to know that I can use your code!
If I can, Could you tell me where should I correct in your code?
Thanks:)

It should work as well as nano.
The machine specific part of the controller is only https://github.com/mojyack/wave-rover-jetson-car/blob/76c2dfc61aa3b6ae2965f6e0319c683616065be6/jetson/controller/src/config.py#L1 and https://github.com/mojyack/wave-rover-jetson-car/blob/76c2dfc61aa3b6ae2965f6e0319c683616065be6/jetson/controller/src/config.py#L8.

The only thing you have to do to control the car is send commands through a USB serial port. So any sort of software can control the robot.
Since I have few experiences with ROS, I cannot show the example.
If you use ROS, it may be easy to write your controller instead of using one from this repo.

Is there a controlling method without ROS?
i thought that ROS is the only way to control the car...
If you can, could you show me the example using this repo?

Here is a similar project using raspberry pi.
https://github.com/mojyack/rpi-zumo-mobile
It implements QR code tracing in autopilot.py.
It uses PWM and GPIO to control motors, so rewriting the Motor class in daemon.py to use serial commands should make it work in wave rover.


Update README.md

Added installing instructions so that developer does not have to head over to pub to find installing instructions.
~ Thanks for this package
~ Your work on Get is exceptional.

Thank you for your contribution!
I also just saw your profile and you have great repositories!
LGTM


Create option to "delay" a TransitionPresence

In the Immersive Web version we have a useEnabledAnimation hook. These will wait for some certain value to be set to true before calling the animation setups. Ideally I think we just want to have this option with the useAnimation hooks in some ways as well. This would make it easier to delay animations while waiting for content to be loaded or something like that.
I'm not sure what would be the nicest way to implement this, perhaps something together with a TransitionPresence which is "active" by default, but you could also set it to inactive or something?

@ReneDrie I think this can be implemented using the useBeforeUnmount hook, I'll try to make an example when I have time.


How to use different levels?

I don't get how to use different header level. I set levels to [2, 3, 4] in config but this doesn't work.
I still see only single "Header" option in a toolbar.
The demo at the homepage doesn't have different header levels as well.

I have the same issue

This article may help
https://codex.so/editorjs-toolbox

same...Thinking about switching to another editor


Bootstrap + Chrome, inner divs disappear

Hi, I'm having an issue that seems to be Chrome specific.
If I have a grid structure inside my draggable elements, the text inside the columns will disappear on drag.
Here is the example: http://jsbin.com/royusuquda/edit?html,js,output
Trying in firefox, the text will stay.
This may be related to #794, but I'm not interested in completely modifying the dragged image, I just want it to look the same.

I have the same issue. Only in chrome has this issue. I also test my project on Firefox and mobile device, showing there is no problem.

.list-group-item {
  will-change: transform;
}

http://jsbin.com/buzejoyoni/edit?html,css,output

Or try will-change-branch, ex: http://jsbin.com/vulusatase/1/edit?html,output

@RubaXa Home the will-change branch will be merged soon to the master


⚠ API - Lens has degraded performance

In 98b7a67, API - Lens ($LENS_API_URL) experienced degraded performance:

HTTP code: 503
Response time: 330 ms

Resolved: API - Lens performance has improved in 4540494 after 6 minutes.


Fix errors that can occur during shape initialization

Add some better checks during shape initialization. Wait until body is loaded before adding shape.

lgtm

Thanks!


Appstudio update hacbs-test-project-wfve

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI has failed.There was an error creating the PipelineRun: hacbs-test-project-wfve-on-pull-request-
creating pipelinerun hacbs-test-project-wfve-on-pull-request- in namespace rhtap-demo-hunw-tenant has failed.
Tekton Controller has reported this error: the namespace of the provided object does not match the namespace sent on the request


Network latency is not injected into my application

What happened:
Executed Pod Network Latency Experiment, i do not see latency injected into the application
What you expected to happen:
I have a very simple application deployed tom y K8S cluster. The demo application is based on this docker image
How to reproduce it (as minimally and precisely as possible):
Created a basic deployment file that includes the above mentioned image. Created a service account based exactly as specified in this link. Chaos engine manifest also exactly looks like what was in the above mentioned link. I have replaced the app labels wherever appropriate.
When I apply my chaos engine manifest, i can see that k8s creates a pod-network-latency pod as expected. When i look at the logs for the network latency pod, it is able to find the Application pod to inject latency into. Pumba pod appears to get created successfully. I have verified that the network interface of my application pod is eth0. The log files from network latency pod appear to be normal. Here is a sample from it
W0810 16:13:26.444004       1 client_config.go:541] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work. time="2020-08-10T16:13:26Z" level=info msg="[PreReq]: Getting the ENV for the  experiment" time="2020-08-10T16:13:26Z" level=info msg="[PreReq]: Updating the chaos result of pod-network-latency experiment (SOT)" time="2020-08-10T16:13:26Z" level=info msg="The application informations are as follows\n" Namespace=MyNameSPace Label="app=kuard" Ramp Time=0 time="2020-08-10T16:13:26Z" level=info msg="[Status]: Verify that the AUT (Application Under Test) is running (pre-chaos)" time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking whether application pods are in running state" time="2020-08-10T16:13:26Z" level=info msg="The running status of Pods are as follows" Pod=kuard-deployment-6c65d5c8fb-trllp Status=Running time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking whether application containers are in running state" time="2020-08-10T16:13:26Z" level=info msg="The running status of container are as follows" container=kuard Pod=kuard-deployment-6c65d5c8fb-trllp Status=Running time="2020-08-10T16:13:26Z" level=info msg="[Info]: Details of application under chaos injection" NodeName=ip-10-98-83-22.ec2.internal ContainerName=kuard PodName=kuard-deployment-6c65d5c8fb-trllp time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking the status of the helper pod" time="2020-08-10T16:13:26Z" level=info msg="[Status]: Checking whether application pods are in running state" time="2020-08-10T16:13:28Z" level=info msg="The running status of Pods are as follows" Status=Running Pod=pumba-netem-judhlx time="2020-08-10T16:13:28Z" level=info msg="[Status]: Checking whether application containers are in running state" time="2020-08-10T16:13:28Z" level=info msg="The running status of container are as follows" container=pumba Pod=pumba-netem-judhlx Status=Running time="2020-08-10T16:13:28Z" level=info msg="[Wait]: Waiting for 300s till the completion of the helper pod" time="2020-08-10T16:13:28Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:29Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:30Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:31Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:32Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:33Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:34Z" level=info msg="helper pod status: Running" time="2020-08-10T16:13:35Z" level=info msg="helper pod status: Running"
I have port-forwarded my application on port 8080. When I access the website localhost:8080, i expect to see network latency, but i don't seem to see any. All XHR requests, that happens as part of the application are able to execute within 50 ms. Is this expected?
Anything else we need to know?:

@iKarthik thank you for trying litmus. Can you share the details of the K8s platform on which this experiment is being run? Also, does pumba logs show any error?

Hello,
Am on k8s 1.17, deployed on AWS. I do not see any logs from pumba (when i do kubectl logs pumba, i see nothing on stdout)

cc: @uditgaurav

This is interesting. I tried to reproduce this, for that I ran an application pod with the given image (smorant/kuard-amd64:1).
used rbac, experiment and engine from https://hub.litmuschaos.io/generic/pod-network-latency
During the execution of experiment:
NAME                               READY   STATUS    RESTARTS   AGE
nginx-6d876b9d9-sqskm              1/1     Running   0          162m
nginx-network-chaos-runner         1/1     Running   0          14s
pod-network-latency-bctptk-8v4px   1/1     Running   0          5s
pumba-netem-ohlxzj                 1/1     Running   0          4s

Pinging the pod ip from the nodes:
[ec2-user@ip-172-31-24-159 ~]$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=255 time=0.047 ms
From <IP_ADDRESS> icmp_seq=19 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=20 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=21 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=22 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=23 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=24 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=25 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=26 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=27 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=28 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=32 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=33 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=34 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=35 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=36 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=37 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=38 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=39 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=41 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=42 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=43 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=44 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=45 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=46 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=47 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=48 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=49 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=50 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=51 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=52 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=53 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=57 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=58 Destination Host Unreachable
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=255 time=59995 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=255 time=59995 ms
From <IP_ADDRESS> icmp_seq=59 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=60 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=61 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=62 Destination Host Unreachable
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=255 time=59996 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=255 time=59997 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=255 time=60005 ms
From <IP_ADDRESS> icmp_seq=63 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=64 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=65 Destination Host Unreachable
64 bytes from <IP_ADDRESS>: icmp_seq=7 ttl=255 time=60001 ms
64 bytes from <IP_ADDRESS>: icmp_seq=8 ttl=255 time=59993 ms
64 bytes from <IP_ADDRESS>: icmp_seq=9 ttl=255 time=59995 ms
64 bytes from <IP_ADDRESS>: icmp_seq=10 ttl=255 time=60008 ms
From <IP_ADDRESS> icmp_seq=66 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=67 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=68 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=69 Destination Host Unreachable
64 bytes from <IP_ADDRESS>: icmp_seq=11 ttl=255 time=59997 ms
64 bytes from <IP_ADDRESS>: icmp_seq=12 ttl=255 time=59995 ms
64 bytes from <IP_ADDRESS>: icmp_seq=13 ttl=255 time=60002 ms
64 bytes from <IP_ADDRESS>: icmp_seq=14 ttl=255 time=60002 ms
From <IP_ADDRESS> icmp_seq=70 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=71 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=72 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=73 Destination Host Unreachable
64 bytes from <IP_ADDRESS>: icmp_seq=15 ttl=255 time=60007 ms
64 bytes from <IP_ADDRESS>: icmp_seq=16 ttl=255 time=60005 ms
64 bytes from <IP_ADDRESS>: icmp_seq=17 ttl=255 time=60005 ms
64 bytes from <IP_ADDRESS>: icmp_seq=18 ttl=255 time=59997 ms
64 bytes from <IP_ADDRESS>: icmp_seq=121 ttl=255 time=0.041 ms
64 bytes from <IP_ADDRESS>: icmp_seq=122 ttl=255 time=0.042 ms
64 bytes from <IP_ADDRESS>: icmp_seq=123 ttl=255 time=0.053 ms
64 bytes from <IP_ADDRESS>: icmp_seq=124 ttl=255 time=0.054 ms
64 bytes from <IP_ADDRESS>: icmp_seq=125 ttl=255 time=0.045 ms
64 bytes from <IP_ADDRESS>: icmp_seq=126 ttl=255 time=0.042 ms
64 bytes from <IP_ADDRESS>: icmp_seq=127 ttl=255 time=0.053 ms

So I'm able to see some Network Latency Into Application Pod
cc: @iKarthik @ksatchit

@uditgaurav Thanks for following up. I replaced the experiment with the latest version from the link you sent above. When i run it, pumba pod is stuck during container creation. It immediately stops with ContainerCannotRun status. Here is what i see in pumba logs
Events:
  Type     Reason   Age    From                                  Message
  ----     ------   ----   ----                                  -------
  Normal   Pulling  5m32s  kubelet, ip-10-98-81-69.ec2.internal  Pulling image "gaiaadm/pumba:0.6.5"
  Normal   Pulled   5m32s  kubelet, ip-10-98-81-69.ec2.internal  Successfully pulled image "gaiaadm/pumba:0.6.5"
  Normal   Created  5m32s  kubelet, ip-10-98-81-69.ec2.internal  Created container pumba
  Warning  Failed   5m31s  kubelet, ip-10-98-81-69.ec2.internal  Error: failed to start container "pumba": Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"pumba\": executable file not found in $PATH": unknown

Does this mean anything to you? Clearly there is some issue with starting the pumba container, dont know what it is
In terms of workflow, here is what i did

I cleared all my existing experiments
Created a single experiment from the link above
Created rbac for this experiment
Created chaosengine for this experiment

@iKarthik this is due to lib image gaiaadm/pumba:0.6.5. In litmus 1.6.2 all lib images and experiment images are merged into one image that is litmuschaos/go-runner:1.6.2 so that we don't need to pull multiple images for running a single experiment.
You can try replacing lib image with litmuschaos/go-runner:1.6.2 or simply use the below chaosengine while using latest version:
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-network-chaos
  namespace: default
spec:
  # It can be delete/retain
  jobCleanUpPolicy: 'delete'
  # It can be true/false
  annotationCheck: 'true'
  # It can be active/stop
  engineState: 'active'
  #ex. values: ns1:name=percona,ns2:run=nginx
  auxiliaryAppInfo: ''
  monitoring: false
  appinfo:
    appns: 'default'
    # FYI, To see app label, apply kubectl get pods --show-labels
    applabel: 'app=nginx'
    appkind: 'deployment'
  chaosServiceAccount: pod-network-latency-sa
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            #Container name where chaos has to be injected
            - name: TARGET_CONTAINER
              value: 'nginx'

            #Network interface inside target container
            - name: NETWORK_INTERFACE
              value: 'eth0'

            - name: LIB_IMAGE
              value: 'litmuschaos/go-runner:1.6.2'

            - name: NETWORK_LATENCY
              value: '60000'

            - name: TOTAL_CHAOS_DURATION
              value: '60' # in seconds

Change the ENVs acc. (appinfo and namespace and target container name).

@uditgaurav With your file above, i was able to get the pods up and running, so thanks for that. But am still seeing that no latency was injected into the pod. This is how am trying to validate it

I portforward kuard deployment to port 8080 on my local machine
When i access localhost:8080/healthy endpoint on my local machine, i expect to see slow response from the deployment, since latency has been injected into the pod but instead all access to that endpoint happens in under 50 ms.

Please let me know if this method of verification is not going to work if so why. (I don't have a ingress rule defined to be able to access that deployment from outside the cluster at the moment)

Hi @uditgaurav @ksatchit
I'm getting below error with latest version of experiment/libraries
k describe po pumba-netem-h3it3k -nlitmus-chaos
---
Events:
  Type     Reason   Age   From                                 Message
  ----     ------   ----  ----                                 -------
  Normal   Pulling  88s   kubelet, node-10  Pulling image "litmuschaos/go-runner:1.6.2"
  Normal   Pulled   43s   kubelet, node-10  Successfully pulled image "litmuschaos/go-runner:1.6.2"
  Normal   Created  18s   kubelet, node-10  Created container pumba
  Warning  Failed   15s   kubelet, node-10 Error: failed to start container "pumba": Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"netem\": executable file not found in $PATH": unknown

this is my experiment yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name:  prom-chaos-network-latency
  namespace: litmus-chaos
spec:
  # It can be delete/retain
  jobCleanUpPolicy: 'delete'
  # It can be true/false
  annotationCheck: 'false'
  # It can be active/stop
  engineState: 'active'
  #ex. values: ns1:name=percona,ns2:run=nginx
  auxiliaryAppInfo: ''
  monitoring: false
  appinfo:
    appns: 'monitoring'
    # FYI, To see app label, apply kubectl get pods --show-labels
    applabel: 'app=prometheus'
    applabel: 'prometheus=prometheus-operator-prometheus'
    appkind: 'statefulset'
  chaosServiceAccount: litmuschaos-admin
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            #Container name where chaos has to be injected
            - name: TARGET_CONTAINER
              value: 'prometheus'

            #Network interface inside target container
            - name: NETWORK_INTERFACE
              value: 'eth0'

            - name: LIB_IMAGE
              value: 'litmuschaos/go-runner:1.6.2'

            - name: NETWORK_LATENCY
              value: '1000'

            - name: TOTAL_CHAOS_DURATION
              value: '120' # in seconds

Any idea ?

@uditgaurav With your file above, i was able to get the pods up and running, so thanks for that. But am still seeing that no latency was injected into the pod. This is how am trying to validate it

I portforward kuard deployment to port 8080 on my local machine
When i access localhost:8080/healthy endpoint on my local machine, i expect to see slow response from the deployment, since latency has been injected into the pod but instead all access to that endpoint happens in under 50 ms.

Please let me know if this method of verification is not going to work if so why. (I don't have a ingress rule defined to be able to access that deployment from outside the cluster at the moment)

@uditgaurav  I created the necessary ingress rules to access the endpoints outside the cluster. Now am able to see the latency. But oddly enough when i set the NETWORK_LATENCY value to just 400 (milliseconds), i get gateway time out errors (502, 504) when accessing the service when i was just expecting 400 ms latency added to the response duration.
When I delete the network latency experiment, am able to access my service normally (within a few 100 ms). Any idea whats going on here?

@iKarthik , just for additional data, can you check if this behaviour is observed even when the additional latency (injected value) is of a smaller range (50ms-100ms)? Just wanted to see if there is a percentage of latency added at the gateway itself as we go.

Hi @uditgaurav @ksatchit
I'm getting below error with latest version of experiment/libraries
k describe po pumba-netem-h3it3k -nlitmus-chaos
---
Events:
  Type     Reason   Age   From                                 Message
  ----     ------   ----  ----                                 -------
  Normal   Pulling  88s   kubelet, node-10  Pulling image "litmuschaos/go-runner:1.6.2"
  Normal   Pulled   43s   kubelet, node-10  Successfully pulled image "litmuschaos/go-runner:1.6.2"
  Normal   Created  18s   kubelet, node-10  Created container pumba
  Warning  Failed   15s   kubelet, node-10 Error: failed to start container "pumba": Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"netem\": executable file not found in $PATH": unknown

this is my experiment yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name:  prom-chaos-network-latency
  namespace: litmus-chaos
spec:
  # It can be delete/retain
  jobCleanUpPolicy: 'delete'
  # It can be true/false
  annotationCheck: 'false'
  # It can be active/stop
  engineState: 'active'
  #ex. values: ns1:name=percona,ns2:run=nginx
  auxiliaryAppInfo: ''
  monitoring: false
  appinfo:
    appns: 'monitoring'
    # FYI, To see app label, apply kubectl get pods --show-labels
    applabel: 'app=prometheus'
    applabel: 'prometheus=prometheus-operator-prometheus'
    appkind: 'statefulset'
  chaosServiceAccount: litmuschaos-admin
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            #Container name where chaos has to be injected
            - name: TARGET_CONTAINER
              value: 'prometheus'

            #Network interface inside target container
            - name: NETWORK_INTERFACE
              value: 'eth0'

            - name: LIB_IMAGE
              value: 'litmuschaos/go-runner:1.6.2'

            - name: NETWORK_LATENCY
              value: '1000'

            - name: TOTAL_CHAOS_DURATION
              value: '120' # in seconds

Any idea ?

Figured with @suhrud-kumar from a slack conversation that the go-runner image tag was latest in ChaosExperiment CR (CR having been picked off the master branch). This has since been changed to 1.6.2 (now sourced from the versioned hub) & the experiment is now seen to execute as expected.

Wel...I found another bug ;D
I install litmus via documentation and try network experiment, BUT pumba got wrong regexp information.
Some technical details:
Deployment name: alertproxy
Pod name: alertproxy
Container name: alertproxy
Docker container: k8s_alertproxy_alertproxy-c8f9ff594-vrfxs_test_7c621948-13ba-11eb-8553-005056011328_0
Technical pod container: k8s_POD_alertproxy-c8f9ff594-vrfxs_test_7c621948-13ba-11eb-8553-005056011328_0
Pumba regexp: k8s_POD_alertproxy-c8f9ff594-vrfxs_test
So the main idea is that the pumba got wrong regexp value. It must be k8s_alertproxy_alertproxy not k8s_POD_alertproxy
Cloud: OKD 3.11
cc @suhrud-kumar @uditgaurav

@Asgoret this is intentional. We are targeting the pause container associated with the app instead of the app itself - to cover for cases where there are liveness probes (which restart the app containers and modify the ID. The pause container OTOH is not restarted/affected. Consider the pause shares the network namespace with app pod, this is a better choice to help unhindered revert of chaos once the chaos duration is complete)

@iKarthik , just for additional data, can you check if this behaviour is observed even when the additional latency (injected value) is of a smaller range (50ms-100ms)? Just wanted to see if there is a variable percentage of latency added at the gateway/ingress controller itself as we go.

I suppose the original issue of not being able to inject latency was resolved for @iKarthik . The question seems to be an unexpected amount of latency. Can you confirm this: https://github.com/litmuschaos/litmus/issues/1853#issuecomment-673918504
Also,  recent versions of the experiment also support: (a) litmus lib for n/w latency (you don't have to pull pumba images) (b) restrict traffic to specific destination IPs/hosts

Closing this issue due to lack of recent updates. Please re-open if things continue to not work with latest litmus releases.


fix: return diff on unchanged methods ignored

This fixes #219 by ignoring return value diffs in unchanged methods.

@khaes-kth thanks! Feel free to publish releases after such PRs


update new padding section in navbar

update new padding section in navbar

Update new scroll button up and down in home page @

@ak-0283 pr closed due to issue not assigned


Odd casting behaviour of signal.filtfilt

I've noticed that signal.filtfilt(b, a, x) always returns a float64 result, even when b, a and x are all float32 (float16 does not seem to be supported by lfilter).
import numpy as np
from scipy import signal

x = np.random.randn(1000)
b, a = signal.butter(8, 0.125)

print(signal.filtfilt( b, a, x).dtype)
# np.float64

print(signal.filtfilt( b.astype(np.float32),
                       a.astype(np.float32),
                       x.astype(np.float32)).dtype)
# still np.float64

Ordinarily this upcasting wouldn't be a big deal, but I'm currently trying to filter some very large arrays, and I'm running into nasty memory issues.
The problem seems to be in signal.lfilter_zi(b, a), which gets called by filtfilt and always returns a float64 result regardless of what dtype b and a have.

Can this behavior in signal.filtfilt and signal.lfilter_zi be fixed? I'll dig into why the latter always returns float64.

Sounds reasonable to me. I think the other filter functions try to retain the filter types. @e-q WDYT?

Preserving the dtype makes sense to me, at least when the input is float32.   A reasonable goal is for filtfilt to do as good a job at preserving the dtype as lfilter does.

I just ran into this too.
The coefficients from the filter design are already in float64 - I didn't look at the filtfilt code yet, but since they are involved in the calculation of the filtered signal this might be one reason.
Merely casting the coefficients b, a to lower precision might cause instability though. So I think the most reasonable thing would be to maintain the type between input and output of filtfilt.
Question: How costly is casting back and forth? It might make sense to do the entire filtering operation in float32 if the input is float32 to avoid casting back and forth twice.

Using the attached script, I tested a few filter-related functions in scipy 1.4.1; it seems like the following return float64 when given all float32 arguments:

decimate
filtfilt
lfilter_zi
sos2tf
sosfilt_zi
sosfiltfilt

One function, lfiltic, returns float32 even when given some float64 arguments, but returns float64 when given all float64 arguments, and float32 when given all float32 arguments.
The following functions behave as expected, or at least as I expect: if any argument is float64, the result is float64, and if all arguments are float32, the result is float32:

lfilter
savgol_filter
sosfilt

decimate:
  (f32) -> f64, np.result_type f32
filtfilt:
  (f32,f32,f32) -> f64, np.result_type f32
lfilter_zi:
  (f32,f32) -> f64, np.result_type f32
lfiltic(3):
  (f32,f64,f32) -> f32, np.result_type f64
  (f64,f32,f32) -> f32, np.result_type f64
  (f64,f64,f32) -> f32, np.result_type f64
lfiltic(4):
  (f32,f32,f32,f64) -> f32, np.result_type f64
  (f32,f64,f32,f32) -> f32, np.result_type f64
  (f32,f64,f32,f64) -> f32, np.result_type f64
  (f64,f32,f32,f32) -> f32, np.result_type f64
  (f64,f32,f32,f64) -> f32, np.result_type f64
  (f64,f64,f32,f32) -> f32, np.result_type f64
  (f64,f64,f32,f64) -> f32, np.result_type f64
sos2tf[0]:
  (f32) -> f64, np.result_type f32
sos2tf[1]:
  (f32) -> f64, np.result_type f32
sosfilt_zi:
  (f32) -> f64, np.result_type f32
sosfiltfilt:
  (f32,f32) -> f64, np.result_type f32

Types as expected:
  lfilter[0]
  lfilter[1]
  savgol_filter
  sosfilt[0]
  sosfilt[1]

check_types.zip

Some of them are inherently not flexible due to calling some underlying C machinery and only available for floats.

@roryyorke would you be up for making a PR to fix some of these? For example fixing lfilter_zi and sosfilt_zi would probably make fixing filtfilt and sosfiltfilt pretty easy.

... one option is just to cast the result of lfilter_zi and sosfilt_zi after they're created, if necessary.


Support for multy GPUs

System Info / 系統信息
AWS EC2
V100 x 4
Information / 问题信息

[X] The official example scripts / 官方的示例脚本
[X] My own modified scripts / 我自己修改的脚本和任务

Reproduction / 复现过程

The code has been modified
but it still says

Expected behavior / 期待表现
Fixed the bug

the cli_demo.py

check the comment in this code,remove cpu_offload,


Needs a license file

Would like to use this, but the project currently has no LICENSE file. (Given a contribution-friendly license I'd like to send a pull request or two to make this accessible as a library if you're up for it as well.)
Looks like original project has a BSD-style license: https://github.com/cmatsuoka/figlet/blob/master/LICENSE

(Also kudos on this library being far more complete than others I've found in go :+1:)

Thanks for pointing that out. Yes, please send pull requests :smile:


Doesn't work. Not saving MP3

A couple of issues. It doesn't read the OPEN_API_KEY environmental variable. I've restarted the Python shell and it's still the same. Had to manually hardcode my API key in your script.
After that is resolved, I then tried to start recording as "test.mp3" into D:\ drive. It shows recording started and when I stopped it, nothing gets created. Tried this a few times and it's the same thing.

@chaoscreater For the OPEN_API_KEY you have to create a ".env" file with your API Key. like :
OPEN_API_KEY=$yourapikey

are you sure you have installed all the requierements ?
foo@bar:~$ pip install -r requirements.txt

@chaoscreater For the OPEN_API_KEY you have to create a ".env" file with your API Key. like :
OPEN_API_KEY=$yourapikey

are you sure you have installed all the requierements ?
foo@bar:~$ pip install -r requirements.txt

Yes I installed all the requirements. It wouldn't even have been able to run if I'm missing the packages.

I assume youre on Windows. You need to change the microhone input in cli.py

I assume youre on Windows. You need to change the microhone input in cli.py

Yes, I'm on Windows. I've searched for "microphone" or anything related to microphone in that file and don't see anything that I could change. Could you provide the line number, or an example of what that change looks like please?

in stream. Mine looks like this
The command to record audio using FFmpeg on macOS
    stream = (
        ffmpeg
        .input("audio=Headset (Jabra Hands-Free AG Audio)", f="dshow")
        .output(output_filename, acodec="libmp3lame", format="mp3")
        .overwrite_output()

I have the same problem on Windows11.

Sadly got the same problem here on window 10


Training the model

Hello Nvidia AI-IOT team,
First of all thank you very much for your effort in creating this code. I am Zeyan and currently working on real time pose estimation implementation on Jetson AGX Xavier.
My goal is to use Depths image (from Intel real sense camera) and check whether the depths information could help improve the performance of pose estimation or not.
Before I conduct my experiments. First I wish to train the model  to act as an base line for our experiments. From  your training script it seems config.json file is required to trained the network. As i wish to follow your parameters for this baseline training.  It would be great if you could provide me your conifg file so that I could follow your step and parameters to train your model.
Thanks in advance for your help and support. I will be looking forward for your reply. Please let me know if you have anything to say,
Thanks
Dr. Zeyan Oo

Hi dy1ngs0ul,
Thanks for reaching out!
You may find the training configuration files in this directory
https://github.com/NVIDIA-AI-IOT/trt_pose/blob/master/tasks/human_pose/experiments/resnet18_baseline_att_224x224_A.json
Please let me know if you have any questions.
Best,
John

Thanks for your help

@jaybdub , Thans for your excellent work!
So far I think cmap_channels means keypoint numbers,  paf_channels  equals to 2*connections, Can you explain upsample_channels means?
"model": {
        "name": "densenet121_baseline_att",
        "kwargs": {
            "cmap_channels": 18,
            "paf_channels": 42,
            "upsample_channels": 256,
            "num_upsample": 3
        }
    },

Hi guys! Have any of you succesfully completed any training using the script provided within the repo?
I'm trying to prune the models but I can't seem to be able to proceed with retraining using train.py because of inconcistency between paf tensors' size:
Traceback (most recent call last):   File "provaTrain.py", line 150, in <module>     paf_mse = torch.mean(mask * (paf_out - paf)**2)   File "/usr/local/lib/python3.6/dist-packages/apex-0.1-py3.6-linux-x86_64.egg/apex/amp/wrap.py", line 58, in wrapper     return orig_fn(*new_args, **kwargs) RuntimeError: The size of tensor a (42) must match the size of tensor b (38) at non-singleton dimension 1

I solved it myself, thank you anyway!

Hey all, I'm having a similar error as @NicolaGugole using the training dataset downloaded through the provided shell script.
Any tips on how to fix this would be greatly appreciated !

Hey all, I'm having a similar error as @NicolaGugole using the training dataset downloaded through the provided shell script.
Any tips on how to fix this would be greatly appreciated !
Edit:Nevermind, one just has to edit the model attribute of the json file referenced earlier to match tensor sizes.

In my case I had to change the annotation file because I noticed a difference between the annotation keypoints number (17 keypoints) and the human_pose.json number (18 keypoints). This difference in tensor sizes is weird in my opinion.
Forcing this sizes to match does not create a fruitful training in my case, I assume because of the fact that the annotation files contain values created to match 17 keypoints while we modified them to match 18 keypoints.
I noticed that in this config file (https://github.com/NVIDIA-AI-IOT/trt_pose/blob/master/tasks/human_pose/experiments/resnet18_baseline_att_224x224_A.json) the devs used a "modified" version of the json file. I hope in the near future we'll have the opportunity to take a look at the modified version of these json files (maybe the devs could upload the files to this repo).
So I have a question @OliverGuy : did you just change the kwargs cmap_channels and paf_channels in the json file referenced earlier? Did that do the job? I tried to do the same but ended up with other conflicts.
Sorry for bothering you all,
Have a nice day!

I only modified those in the json, but I'm having issues with CudNN not finding the convolution algorithm (see #54).

@NicolaGugole
You have to pre-process the coco annotations. This adds the "Neck" keypoint (midpoint of shoulders) so that you will have 18 keypoints. Use the command:
python3 preprocess_coco_person.py annotations/person_keypoints_train2017.json annotations/person_keypoints_train2017_modified.json


Add slackin badge

https://github.com/rauchg/slackin

Slackin looks awesome. Does this mean there's going to be a public slack for Bootstrap nerds?

Looks nice

:+1:

:+1:

@djch getboostrap.slack.com

Done!


feat: TOS-789 en.json changes

Jira: https://testsigma.atlassian.net/browse/TOS-789
en.json fix

https://github.com/testsigmahq/testsigma/pull/269 has been merged instead


copy/paste don't exist in right click menu

When I did a workshop with some teachers getting them into javascript coding, they wanted to copy paste text via the right click menu, they didn't know about ctrl+c ctrl+v. But in Chrome, Firefox and Edge it seems copy/cut/paste don't show up in the right click menu. It does exist in Internet Explorer.

Similar to https://github.com/Microsoft/pxt/issues/2051, closing this one


[WIP] proc/breakpoint Add breakpoint statistics

This adds support for breakpoints statistics
Fixes #247

I'd like to work a bit more on this, such as adding the information about how many times a breakpoint was hit in a certain goroutine but before that I'd like to hear about, if it would be a good idea or not.

@derekparker I have two things about this PR:

can you please point me to how to create the tests for it?
in the following sample:

package main

import (
	"fmt"
	"math/rand"
	"sync"
	"time"
)

func demo(id int, wait *sync.WaitGroup) {
	for i := 0; i < 100; i++ {
		sleep := rand.Intn(10) + 1
		fmt.Printf("id: %d step: %d sleeping %d\n", id, i, sleep)
		time.Sleep(time.Duration(sleep) * time.Millisecond)
	}

	wait.Done()
}

func main() {
	wait := new(sync.WaitGroup)
	wait.Add(1)
	wait.Add(1)
	go demo(1, wait)
	go demo(2, wait)

	wait.Wait()
}

setting a tracepoint on line 12, sleep := rand.Intn(10) + 1 would show that the tracepoint doesn't necessarily always show when the line is reached. For example, I have something like this on a test run:
id: 1 step: 99 sleeping 7
id: 2 step: 98 sleeping 1
> main.demo() /home/florin/golang/src/github.com/dlsniper/u/dbg/demo4/demo4.go:12 (hits goroutine(6):59 total:112)

id: 2 step: 99 sleeping 7

What OS are you using?
Suppose the two goroutines are running on two separate threads, since the loop in demo is so tight and the sleep so relatively it would sometimes happen that both goroutines get to the breakpoint simultaneously. It may seem strange but consider that a lot of code needs to execute inside the kernel between a thread hitting a breakpoint and our waitpid call returning and part of that will count as 'simultaneous'.
This is one thing that could be happening.

I'm on Ubuntu 15.04 x64 Linux sniper 4.2.0-040200-generic #201508301530 SMP Sun Aug 30 19:31:40 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

In that case could you try to disable hardware breakpoints by putting an if false around the for loop at proc/breakpoints.go:101? For some reason they are less reliable for me.

Thanks, I've tried that as well but with the same result.
After thinking a bit on how goroutines work, this might be a problem caused by the fact that the breakpoint is set in the same thread even if multiple goroutines are used. Further investigation is required. What I've said might also be completely useless or dumb.

Merged.