InferenceGraph tutorial is not working

/kind bug
What steps did you take and what happened:
I follow the official tutorial by this link:
_https://kserve.github.io/website/0.10/modelserving/inference_graph/image_pipeline/#deploy-the-inferenceservices_
What did you expect to happen:
Same as the tutorial, isvc of 2 classifiers will be online
What's the InferenceService yaml:
[To help us debug please run kubectl get isvc $name -n $namespace -oyaml and paste the output]
============================================================================
apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
name: "cat-dog-classifier"
spec:
predictor:
pytorch:
storageUri: gs://kfserving-examples/models/torchserve/cat_dog_classification
apiVersion: "serving.kserve.io/v1beta1"
kind: "InferenceService"
metadata:
name: "dog-breed-classifier"
spec:
predictor:
pytorch:
resources:
requests:
cpu: 100m
storageUri: gs://kfserving-examples/models/torchserve/dog_breed_classification
DETAIL description of two isvc:
============================================================================
kubectl describe pod cat-dog-classifier-predictor-default-00001-deployment-bb66qhms4 -n default
Name:         cat-dog-classifier-predictor-default-00001-deployment-bb66qhms4
Namespace:    default
Priority:     0
Node:         e2m122-pc/<IP_ADDRESS>
Start Time:   Fri, 07 Apr 2023 18:19:41 +0800
Labels:       app=cat-dog-classifier-predictor-default-00001
component=predictor
pod-template-hash=bb665cddc
service.istio.io/canonical-name=cat-dog-classifier-predictor-default
service.istio.io/canonical-revision=cat-dog-classifier-predictor-default-00001
serviceEnvelope=kserve
serving.knative.dev/configuration=cat-dog-classifier-predictor-default
serving.knative.dev/configurationGeneration=1
serving.knative.dev/configurationUID=029fdcf4-ad95-40d3-b3c3-ea81ab73fa23
serving.knative.dev/revision=cat-dog-classifier-predictor-default-00001
serving.knative.dev/revisionUID=2c49d609-6ee5-47d2-8e2a-5cf55ed7a834
serving.knative.dev/service=cat-dog-classifier-predictor-default
serving.knative.dev/serviceUID=3aa62558-551d-4b98-b9f0-f8b23e453be6
serving.kserve.io/inferenceservice=cat-dog-classifier
Annotations:  autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
autoscaling.knative.dev/min-scale: 1
container.seccomp.security.alpha.kubernetes.io/queue-proxy: runtime/default
internal.serving.kserve.io/storage-initializer-sourceuri: gs://kfserving-examples/models/torchserve/cat_dog_classification
prometheus.kserve.io/path: /metrics
prometheus.kserve.io/port: 8082
serving.knative.dev/creator: system:serviceaccount:kubeflow:kserve-controller-manager
serving.kserve.io/enable-metric-aggregation: false
serving.kserve.io/enable-prometheus-scraping: false
Status:       Running
IP:           <IP_ADDRESS>
IPs:
IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/cat-dog-classifier-predictor-default-00001-deployment-bb665cddc
Init Containers:
storage-initializer:
Container ID:  containerd://e2fd3ca41bf91e61bee9a05b219815c8a028596c9d80000e11bd79e38f6d0150
Image:         kserve/storage-initializer:v0.10.0
Image ID:      docker.io/kserve/storage-initializer@sha256:ae248f55efbbd33f1f6ac088863379036b6b11d26e8715ca43c4a3efcbc39687
Port:
Host Port:
Args:
gs://kfserving-examples/models/torchserve/cat_dog_classification
/mnt/models
State:          Terminated
Reason:       Completed
Exit Code:    0
Started:      Fri, 07 Apr 2023 18:19:42 +0800
Finished:     Fri, 07 Apr 2023 18:19:59 +0800
Ready:          True
Restart Count:  0
Limits:
cpu:     1
memory:  1Gi
Requests:
cpu:        100m
memory:     100Mi
Environment:
Mounts:
/mnt/models from kserve-provision-location (rw)
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-5ctvf (ro)
Containers:
kserve-container:
Container ID:  containerd://d57c288e9b371e9866a8e48fd900890003800c9de8d55603e5e0607e581b2b83
Image:         index.docker.io/pytorch/torchserve-kfs@sha256:05eff20e927746993dff9b4d2a441cf194902c665027976ed90d841dcbb7ac5f
Image ID:      docker.io/pytorch/torchserve-kfs@sha256:05eff20e927746993dff9b4d2a441cf194902c665027976ed90d841dcbb7ac5f
Port:          8080/TCP
Host Port:     0/TCP
Args:
torchserve
--start
--model-store=/mnt/models/model-store
--ts-config=/mnt/models/config/config.properties
State:      Terminated
Reason:   Error
Message:  refer direct buffer: false
Allowed Urls: [file://.|http(s)?://.]
Custom python dependency for model allowed: true
Metrics report format: prometheus
Enable metrics API: true
Workflow Store: /mnt/models/model-store
Model config: N/A
2023-04-07T10:20:53,481 [INFO ] main org.pytorch.serve.servingsdk.impl.PluginsManager -  Loading snapshot serializer plugin...
2023-04-07T10:20:53,562 [INFO ] main org.pytorch.serve.snapshot.SnapshotManager - Started restoring models from snapshot {"name":"startup.cfg","modelCount":2,"models":{"cat-dog-classifier":{"1.0":{"defaultVersion":true,"marName":"cat_dog_classification.mar","minWorkers":1,"maxWorkers":5,"batchSize":1,"maxBatchDelay":5000,"responseTimeout":120}}, "dog-breed-classifier":{"1.0":{"defaultVersion":true,"marName":"dog_breed_classification.mar","minWorkers":1,"maxWorkers":5,"batchSize":1,"maxBatchDelay":5000,"responseTimeout":120}}}}
2023-04-07T10:20:53,566 [INFO ] main org.pytorch.serve.snapshot.SnapshotManager - Validating snapshot startup.cfg
2023-04-07T10:20:53,566 [INFO ] main org.pytorch.serve.snapshot.SnapshotManager - Snapshot startup.cfg validated successfully
[I 230407 10:20:54 main:70] Wrapper : Model names ['cat-dog-classifier', 'dog-breed-classifier'], inference address http//<IP_ADDRESS>:8085, management address http://<IP_ADDRESS>:8085, model store /mnt/models/model-store
[I 230407 10:20:54 TorchserveModel:52] kfmodel Predict URL set to <IP_ADDRESS>:8085
[I 230407 10:20:54 TorchserveModel:54] kfmodel Explain URL set to <IP_ADDRESS>:8085
[I 230407 10:20:54 storage:63] Copying contents of /mnt/models/model-store to local
Traceback (most recent call last):
File "/home/model-server/kserve_wrapper/main.py", line 95, in
model.load()
File "/home/model-server/kserve_wrapper/TorchserveModel.py", line 133, in load
raise RuntimeError(
RuntimeError: More than one model file is detected, Only one is allowed within model_dir: [PosixPath('/mnt/models/model-store/dog_breed_classification.mar'), PosixPath('/mnt/models/model-store/cat_dog_classification.mar')]
  Exit Code:  1
  Started:    Fri, 07 Apr 2023 18:20:51 +0800
  Finished:   Fri, 07 Apr 2023 18:20:54 +0800
Last State:   Terminated
  Reason:     Error
  Message:    t startup.cfg

2023-04-07T10:20:22,460 [INFO ] main org.pytorch.serve.snapshot.SnapshotManager - Snapshot startup.cfg validated successfully
[I 230407 10:20:23 main:70] Wrapper : Model names ['cat-dog-classifier', 'dog-breed-classifier'], inference address http//<IP_ADDRESS>:8085, management address http://<IP_ADDRESS>:8085, model store /mnt/models/model-store
[I 230407 10:20:23 TorchserveModel:52] kfmodel Predict URL set to <IP_ADDRESS>:8085
[I 230407 10:20:23 TorchserveModel:54] kfmodel Explain URL set to <IP_ADDRESS>:8085
[I 230407 10:20:23 storage:63] Copying contents of /mnt/models/model-store to local
Traceback (most recent call last):
File "/home/model-server/kserve_wrapper/main.py", line 95, in
model.load()
File "/home/model-server/kserve_wrapper/TorchserveModel.py", line 133, in load
raise RuntimeError(
RuntimeError: More than one model file is detected, Only one is allowed within model_dir: [PosixPath('/mnt/models/model-store/dog_breed_classification.mar'), PosixPath('/mnt/models/model-store/cat_dog_classification.mar')]
2023-04-07T10:20:23,493 [DEBUG] main org.pytorch.serve.wlm.ModelVersionedRefs - Adding new version 1.0 for model cat-dog-classifier
2023-04-07T10:20:23,493 [DEBUG] main org.pytorch.serve.wlm.ModelVersionedRefs - Setting default version to 1.0 for model cat-dog-classifier
2023-04-07T10:20:23,545 [DEBUG] main org.pytorch.serve.wlm.ModelVersionedRefs - Setting default version to 1.0 for model cat-dog-classifier
2023-04-07T10:20:23,546 [INFO ] main org.pytorch.serve.wlm.ModelManager - Model cat-dog-classifier loaded.
2023-04-07T10:20:23,546 [DEBUG] main org.pytorch.serve.wlm.ModelManager - updateModel: cat-dog-classifier, count: 1
2023-04-07T10:20:23,554 [DEBUG] W-9000-cat-dog-classifier_1.0 org.pytorch.serve.wlm.WorkerLifeCycle - Worker cmdline: [/usr/bin/python3.8, /usr/local/lib/python3.8/dist-packages/ts/model_service_worker.py, --sock-type, unix, --sock-name, /home/model-server/tmp/.ts.sock.9000, --metrics-config, /usr/local/lib/python3.8/dist-packages/ts/configs/metrics.yaml]
  Exit Code:    1
  Started:      Fri, 07 Apr 2023 18:20:20 +0800
  Finished:     Fri, 07 Apr 2023 18:20:23 +0800
Ready:          False
Restart Count:  3
Limits:
  cpu:     1
  memory:  2Gi
Requests:
  cpu:     1
  memory:  2Gi
Environment:
  TS_SERVICE_ENVELOPE:  kserve
  PORT:                 8080
  K_REVISION:           cat-dog-classifier-predictor-default-00001
  K_CONFIGURATION:      cat-dog-classifier-predictor-default
  K_SERVICE:            cat-dog-classifier-predictor-default
Mounts:
  /mnt/models from kserve-provision-location (ro)
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-5ctvf (ro)

queue-proxy:
Container ID:   containerd://8331ba05b9d41daccafeb9252acca92f4e55d35886aee410c3eebdeaa31727d5
Image:          gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c
Image ID:       gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c
Ports:          8022/TCP, 9090/TCP, 9091/TCP, 8012/TCP, 8112/TCP
Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
State:          Running
Started:      Fri, 07 Apr 2023 18:20:00 +0800
Ready:          False
Restart Count:  0
Requests:
cpu:      25m
Readiness:  http-get http://:8012/ delay=0s timeout=1s period=10s #success=1 #failure=3
Environment:
SERVING_NAMESPACE:                        default
SERVING_SERVICE:                          cat-dog-classifier-predictor-default
SERVING_CONFIGURATION:                    cat-dog-classifier-predictor-default
SERVING_REVISION:                         cat-dog-classifier-predictor-default-00001
QUEUE_SERVING_PORT:                       8012
QUEUE_SERVING_TLS_PORT:                   8112
CONTAINER_CONCURRENCY:                    0
REVISION_TIMEOUT_SECONDS:                 300
REVISION_RESPONSE_START_TIMEOUT_SECONDS:  0
REVISION_IDLE_TIMEOUT_SECONDS:            0
SERVING_POD:                              cat-dog-classifier-predictor-default-00001-deployment-bb66qhms4 (v1:metadata.name)
SERVING_POD_IP:                            (v1:status.podIP)
SERVING_LOGGING_CONFIG:
SERVING_LOGGING_LEVEL:
SERVING_REQUEST_LOG_TEMPLATE:             {"httpRequest": {"requestMethod": "{{.Request.Method}}", "requestUrl": "{{js .Request.RequestURI}}", "requestSize": "{{.Request.ContentLength}}", "status": {{.Response.Code}}, "responseSize": "{{.Response.Size}}", "userAgent": "{{js .Request.UserAgent}}", "remoteIp": "{{js .Request.RemoteAddr}}", "serverIp": "{{.Revision.PodIP}}", "referer": "{{js .Request.Referer}}", "latency": "{{.Response.Latency}}s", "protocol": "{{.Request.Proto}}"}, "traceId": "{{index .Request.Header "X-B3-Traceid"}}"}
SERVING_ENABLE_REQUEST_LOG:               false
SERVING_REQUEST_METRICS_BACKEND:          prometheus
TRACING_CONFIG_BACKEND:                   none
TRACING_CONFIG_ZIPKIN_ENDPOINT:
TRACING_CONFIG_DEBUG:                     false
TRACING_CONFIG_SAMPLE_RATE:               0.1
USER_PORT:                                8080
SYSTEM_NAMESPACE:                         knative-serving
METRICS_DOMAIN:                           knative.dev/internal/serving
SERVING_READINESS_PROBE:                  {"tcpSocket":{"port":8080,"host":"<IP_ADDRESS>"},"successThreshold":1}
ENABLE_PROFILING:                         false
SERVING_ENABLE_PROBE_REQUEST_LOG:         false
METRICS_COLLECTOR_ADDRESS:
CONCURRENCY_STATE_ENDPOINT:
CONCURRENCY_STATE_TOKEN_PATH:             /var/run/secrets/tokens/state-token
HOST_IP:                                   (v1:status.hostIP)
ENABLE_HTTP2_AUTO_DETECTION:              false
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-5ctvf (ro)
Conditions:
Type              Status
Initialized       True
Ready             False
ContainersReady   False
PodScheduled      True
Volumes:
kube-api-access-5ctvf:
Type:                    Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds:  3607
ConfigMapName:           kube-root-ca.crt
ConfigMapOptional:
DownwardAPI:             true
kserve-provision-location:
Type:        EmptyDir (a temporary directory that shares a pod's lifetime)
Medium:
SizeLimit:
QoS Class:       Burstable
Node-Selectors:
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type     Reason     Age                From               Message

Normal   Scheduled  77s                default-scheduler  Successfully assigned default/cat-dog-classifier-predictor-default-00001-deployment-bb66qhms4 to e2m122-pc
Normal   Pulled     77s                kubelet            Container image "kserve/storage-initializer:v0.10.0" already present on machine
Normal   Created    77s                kubelet            Created container storage-initializer
Normal   Started    76s                kubelet            Started container storage-initializer
Normal   Pulled     58s                kubelet            Container image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c" already present on machine
Normal   Created    58s                kubelet            Created container queue-proxy
Normal   Started    58s                kubelet            Started container queue-proxy
Warning  BackOff    50s                kubelet            Back-off restarting failed container
Normal   Pulled     38s (x3 over 58s)  kubelet            Container image "index.docker.io/pytorch/torchserve-kfs@sha256:05eff20e927746993dff9b4d2a441cf194902c665027976ed90d841dcbb7ac5f" already present on machine
Normal   Created    38s (x3 over 58s)  kubelet            Created container kserve-container
Normal   Started    38s (x3 over 58s)  kubelet            Started container kserve-container
Warning  Unhealthy  36s (x9 over 56s)  kubelet            Readiness probe failed: Get "http://<IP_ADDRESS>:8012/": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
============================================================================
Environment:
I installed Kubeflow 1.7 manifest

Istio | common/istio-1-16 | 1.16.0
Knative | common/knative/knative-serving  1.8.1
Cert Manager | common/cert-manager | 1.10.1
Kubeflow version: 1.7
Cloud Environment:[k8s_istio/istio_dex]
Minikube/Kind version:
Kubernetes version: (use kubectl version): 1.24.12
OS (e.g. from /etc/os-release): Ubuntu 20.04

/assign @sivanantha321

@yuzisun From the below image you can see that both storage links contains two models. As I understand from this code reference,  torchserve does not allow more than 1 model to be loaded?. If we remove the redundant model and update the config.properties, it should work fine. I will raise a separate PR for improving the document.

@sivanantha321 It seems like this logic is recently added in https://github.com/pytorch/serve/commit/3c4ee71812e2d090fd6efd3a9a10c39cf87af25a by @jagadeeshi2i

@sivanantha321  @yuzisun Thank you for your reply,
FYI, I've successfully deployed the 2 inference services in the tutorial on Kubernetes 1.21.12 and Kubeflow 1.6.1 but when applying the last yaml file from the tutorial can't run on Ksever 0.8:
kubectl apply -f - <<EOF
apiVersion: "serving.kserve.io/v1alpha1"
kind: "InferenceGraph"
metadata:
name: "dog-breed-pipeline"
spec:
nodes:
root:
routerType: Sequence
steps:
- serviceName: cat-dog-classifier
name: cat_dog_classifier # step name
- serviceName: dog-breed-classifier
name: dog_breed_classifier
data: $request
condition: "[@this].#(predictions.0=="dog")"
EOF

@sivanantha321 @yuzisun Thank you for your reply, FYI, I've successfully deployed the 2 inference services in the tutorial on Kubernetes 1.21.12 and Kubeflow 1.6.1 but when applying the last yaml file from the tutorial it can't run on Ksever 0.8:
kubectl apply -f - <<EOF apiVersion: "serving.kserve.io/v1alpha1" kind: "InferenceGraph" metadata: name: "dog-breed-pipeline" spec: nodes: root: routerType: Sequence steps: - serviceName: cat-dog-classifier name: cat_dog_classifier # step name - serviceName: dog-breed-classifier name: dog_breed_classifier data: $request condition: "[@this].#(predictions.0=="dog")" EOF

@Sundragon1993  It is expected as  InferenceGraph is introduced in kserve 0.9

Hi @Sundragon1993 can you try changing the inference service with this image: jagadeeshj/torchserve-kfs:0.7.0
Refer:
https://github.com/kserve/kserve/blob/ff8eb9e79b701e50bd700259fc5bcb0def4d680a/docs/samples/v1beta1/tensorflow/versioning.yaml#L6

@jagadeeshi2i @sivanantha321 Thank you so much for the reply,
I confirm that the image you provided works perfectly. Even though the inference graph is now online, I couldn't request into this kind of inference graph using curl as denoted in the tutorial. Is there any way to get the ig using kserve SDK? For ex: KServe.get(ig_name, namespace=namespace)
import requests
# isvc_url = isvc_resp['status']['address']['url']
ig_url = "http://dog-breed-pipeline.kubeflow-user-example-com.svc.cluster.local"
print(isvc_url)
response = requests.post(ig_url, json=cat_input)
print(response.text)

Output:
http://dog-breed-pipeline.kubeflow-user-example-com.svc.cluster.local/
RBAC: access denied

@Sundragon1993 svc.cluster.local domain is not exposed outside the cluster. If you are trying to access from outside the cluster it won't work. If you want to access Inferencegraph from outside the cluster, you should configure a custom domain  or configure a DNS in Knative. Kserve sdk does supports inferencegraph. See the python sdk

@jagadeeshi2i I had the same issue. What you did in https://github.com/kserve/kserve/issues/2799#issuecomment-1510740478 did work for me. Is it possible that you PR those changes?

@yuzisun The torchserve 0.8 is released with the fix for loading multiple models. Can we upgrade the torchserver version?

@jagadeeshi2i Seems like torchserve is using latest kserve 0.10 which removed to tornado in favour of uvicorn. We should update the code.

@sivanantha321 Thanks for your information, however, the pytorch/torchserve-kfs:0.8.0 doesn't work with the current source code, thus I keep using the image: jagadeeshj/torchserve-kfs:0.7.0.
However, when I try to request into the inference graph using pod forward (I couldn't follow the same way as denoted in the tutorial):
kubectl port-forward -n kubeflow-user-example-com pods/dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 8080:8080 --address=<IP_ADDRESS>
the response was:
*   Trying <IP_ADDRESS>:8080...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8080 (#0)
> POST / HTTP/1.1
> Host: <IP_ADDRESS>:8080
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 4269
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Thu, 18 May 2023 07:27:25 GMT
< Content-Length: 43
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host <IP_ADDRESS> left intact

Pod's description:
kubectl describe pods/dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 -n kubeflow-user-example-com
Name:         dog-breed-pipeline-00001-deployment-5c998df47f-g8z62
Namespace:    kubeflow-user-example-com
Priority:     0
Node:         e2m122-pc/<IP_ADDRESS>
Start Time:   Thu, 18 May 2023 15:22:08 +0800
Labels:       app=dog-breed-pipeline-00001
              pod-template-hash=5c998df47f
              security.istio.io/tlsMode=istio
              service.istio.io/canonical-name=dog-breed-pipeline
              service.istio.io/canonical-revision=dog-breed-pipeline-00001
              serving.knative.dev/configuration=dog-breed-pipeline
              serving.knative.dev/configurationGeneration=1
              serving.knative.dev/configurationUID=de856a00-2c2c-4a48-9219-f0588992c68d
              serving.knative.dev/revision=dog-breed-pipeline-00001
              serving.knative.dev/revisionUID=ea9baed8-587c-4f4a-943d-d5ec4fde24f1
              serving.knative.dev/service=dog-breed-pipeline
              serving.knative.dev/serviceUID=71216221-0972-49fb-abaf-0b9ecb0bc51b
Annotations:  autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
              autoscaling.knative.dev/min-scale: 1
              container.seccomp.security.alpha.kubernetes.io/queue-proxy: runtime/default
              kubectl.kubernetes.io/default-container: user-container
              kubectl.kubernetes.io/default-logs-container: user-container
              prometheus.io/path: /stats/prometheus
              prometheus.io/port: 15020
              prometheus.io/scrape: true
              serving.knative.dev/creator: system:serviceaccount:kubeflow:kserve-controller-manager
              sidecar.istio.io/status:
                {"initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["workload-socket","credential-socket","workload-certs","istio-env...
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/dog-breed-pipeline-00001-deployment-5c998df47f
Init Containers:
  istio-init:
    Container ID:  containerd://5a2b97f2b89f6684d5ae30b983d339c93be4ef0ca75142d18def28819e70a95a
    Image:         docker.io/istio/proxyv2:1.16.0
    Image ID:      docker.io/istio/proxyv2@sha256:f6f97fa4fb77a3cbe1e3eca0fa46bd462ad6b284c129cf57bf91575c4fb50cf9
    Port:          <none>
    Host Port:     <none>
    Args:
      istio-iptables
      -p
      15001
      -z
      15006
      -u
      1337
      -m
      REDIRECT
      -i
      *
      -x

      -b
      *
      -d
      15090,15021,15020
      --log_output_level=default:info
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Thu, 18 May 2023 15:22:09 +0800
      Finished:     Thu, 18 May 2023 15:22:09 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:        10m
      memory:     40Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
Containers:
  user-container:
    Container ID:  containerd://ad147f111c0e679f70f3fcc482e1d8896a31a07820123e6ff4953ab95b385095
    Image:         index.docker.io/kserve/router@sha256:e67364a8c9d3d78f0627195eb1945f3e1691f9cb7dd78f57f411fa92b5bce5bb
    Image ID:      docker.io/kserve/router@sha256:e67364a8c9d3d78f0627195eb1945f3e1691f9cb7dd78f57f411fa92b5bce5bb
    Port:          8080/TCP
    Host Port:     0/TCP
    Args:
      --graph-json
      {"nodes":{"root":{"routerType":"Sequence","steps":[{"name":"cat_dog_classifier","serviceName":"cat-dog-classifier","serviceUrl":"http://cat-dog-classifier.kubeflow-user-example-com.svc.cluster.local/v1/models/cat-dog-classifier:predict"},{"name":"dog_breed_classifier","serviceName":"dog-breed-classifier","serviceUrl":"http://dog-breed-classifier.kubeflow-user-example-com.svc.cluster.local/v1/models/dog-breed-classifier:predict","data":"$request","condition":"[@this].#(predictions.0==\"dog\")"}]}}}
    State:          Running
      Started:      Thu, 18 May 2023 15:22:09 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  100Mi
    Environment:
      PORT:             8080
      K_REVISION:       dog-breed-pipeline-00001
      K_CONFIGURATION:  dog-breed-pipeline
      K_SERVICE:        dog-breed-pipeline
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
  queue-proxy:
    Container ID:   containerd://d448564e22e1ba4e2ede69f609601b706e20e8699eea7c3d9e43f866d0e2ff20
    Image:          gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c
    Image ID:       gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c
    Ports:          8022/TCP, 9090/TCP, 9091/TCP, 8012/TCP, 8112/TCP
    Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
    State:          Running
      Started:      Thu, 18 May 2023 15:22:09 +0800
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:      25m
    Readiness:  http-get http://:15020/app-health/queue-proxy/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      SERVING_NAMESPACE:                        kubeflow-user-example-com
      SERVING_SERVICE:                          dog-breed-pipeline
      SERVING_CONFIGURATION:                    dog-breed-pipeline
      SERVING_REVISION:                         dog-breed-pipeline-00001
      QUEUE_SERVING_PORT:                       8012
      QUEUE_SERVING_TLS_PORT:                   8112
      CONTAINER_CONCURRENCY:                    0
      REVISION_TIMEOUT_SECONDS:                 300
      REVISION_RESPONSE_START_TIMEOUT_SECONDS:  0
      REVISION_IDLE_TIMEOUT_SECONDS:            0
      SERVING_POD:                              dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 (v1:metadata.name)
      SERVING_POD_IP:                            (v1:status.podIP)
      SERVING_LOGGING_CONFIG:
      SERVING_LOGGING_LEVEL:
      SERVING_REQUEST_LOG_TEMPLATE:             {"httpRequest": {"requestMethod": "{{.Request.Method}}", "requestUrl": "{{js .Request.RequestURI}}", "requestSize": "{{.Request.ContentLength}}", "status": {{.Response.Code}}, "responseSize": "{{.Response.Size}}", "userAgent": "{{js .Request.UserAgent}}", "remoteIp": "{{js .Request.RemoteAddr}}", "serverIp": "{{.Revision.PodIP}}", "referer": "{{js .Request.Referer}}", "latency": "{{.Response.Latency}}s", "protocol": "{{.Request.Proto}}"}, "traceId": "{{index .Request.Header "X-B3-Traceid"}}"}
      SERVING_ENABLE_REQUEST_LOG:               false
      SERVING_REQUEST_METRICS_BACKEND:          prometheus
      TRACING_CONFIG_BACKEND:                   none
      TRACING_CONFIG_ZIPKIN_ENDPOINT:
      TRACING_CONFIG_DEBUG:                     false
      TRACING_CONFIG_SAMPLE_RATE:               0.1
      USER_PORT:                                8080
      SYSTEM_NAMESPACE:                         knative-serving
      METRICS_DOMAIN:                           knative.dev/internal/serving
      SERVING_READINESS_PROBE:                  {"tcpSocket":{"port":8080,"host":"<IP_ADDRESS>"},"successThreshold":1}
      ENABLE_PROFILING:                         false
      SERVING_ENABLE_PROBE_REQUEST_LOG:         false
      METRICS_COLLECTOR_ADDRESS:
      CONCURRENCY_STATE_ENDPOINT:
      CONCURRENCY_STATE_TOKEN_PATH:             /var/run/secrets/tokens/state-token
      HOST_IP:                                   (v1:status.hostIP)
      ENABLE_HTTP2_AUTO_DETECTION:              false
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
  istio-proxy:
    Container ID:  containerd://c1c49237b59ca98e62e83bcdc54c845c3e785e674084b4b0c8d8cf711e5a7a0e
    Image:         docker.io/istio/proxyv2:1.16.0
    Image ID:      docker.io/istio/proxyv2@sha256:f6f97fa4fb77a3cbe1e3eca0fa46bd462ad6b284c129cf57bf91575c4fb50cf9
    Port:          15090/TCP
    Host Port:     0/TCP
    Args:
      proxy
      sidecar
      --domain
      $(POD_NAMESPACE).svc.cluster.local
      --proxyLogLevel=warning
      --proxyComponentLogLevel=misc:error
      --log_output_level=default:info
      --concurrency
      2
    State:          Running
      Started:      Thu, 18 May 2023 15:22:10 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:      10m
      memory:   40Mi
    Readiness:  http-get http://:15021/healthz/ready delay=1s timeout=3s period=2s #success=1 #failure=30
    Environment:
      JWT_POLICY:                    third-party-jwt
      PILOT_CERT_PROVIDER:           istiod
      CA_ADDR:                       istiod.istio-system.svc:15012
      POD_NAME:                      dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 (v1:metadata.name)
      POD_NAMESPACE:                 kubeflow-user-example-com (v1:metadata.namespace)
      INSTANCE_IP:                    (v1:status.podIP)
      SERVICE_ACCOUNT:                (v1:spec.serviceAccountName)
      HOST_IP:                        (v1:status.hostIP)
      PROXY_CONFIG:                  {}

      ISTIO_META_POD_PORTS:          [
                                         {"name":"user-port","containerPort":8080,"protocol":"TCP"}
                                         ,{"name":"http-queueadm","containerPort":8022,"protocol":"TCP"}
                                         ,{"name":"http-autometric","containerPort":9090,"protocol":"TCP"}
                                         ,{"name":"http-usermetric","containerPort":9091,"protocol":"TCP"}
                                         ,{"name":"queue-port","containerPort":8012,"protocol":"TCP"}
                                         ,{"name":"https-port","containerPort":8112,"protocol":"TCP"}
                                     ]
      ISTIO_META_APP_CONTAINERS:     user-container,queue-proxy
      ISTIO_META_CLUSTER_ID:         Kubernetes
      ISTIO_META_INTERCEPTION_MODE:  REDIRECT
      ISTIO_META_WORKLOAD_NAME:      dog-breed-pipeline-00001-deployment
      ISTIO_META_OWNER:              kubernetes://apis/apps/v1/namespaces/kubeflow-user-example-com/deployments/dog-breed-pipeline-00001-deployment
      ISTIO_META_MESH_ID:            cluster.local
      TRUST_DOMAIN:                  cluster.local
      ISTIO_KUBE_APP_PROBERS:        {"/app-health/queue-proxy/readyz":{"httpGet":{"path":"/","port":8012,"scheme":"HTTP","httpHeaders":[{"name":"K-Network-Probe","value":"queue"}]},"timeoutSeconds":1}}
    Mounts:
      /etc/istio/pod from istio-podinfo (rw)
      /etc/istio/proxy from istio-envoy (rw)
      /var/lib/istio/data from istio-data (rw)
      /var/run/secrets/credential-uds from credential-socket (rw)
      /var/run/secrets/istio from istiod-ca-cert (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
      /var/run/secrets/tokens from istio-token (rw)
      /var/run/secrets/workload-spiffe-credentials from workload-certs (rw)
      /var/run/secrets/workload-spiffe-uds from workload-socket (rw)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  workload-socket:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  credential-socket:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  workload-certs:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  istio-envoy:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     Memory
    SizeLimit:  <unset>
  istio-data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  istio-podinfo:
    Type:  DownwardAPI (a volume populated by information about the pod)
    Items:
      metadata.labels -> labels
      metadata.annotations -> annotations
  istio-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  43200
  istiod-ca-cert:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      istio-ca-root-cert
    Optional:  false
  kube-api-access-c6bzq:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  8m58s  default-scheduler  Successfully assigned kubeflow-user-example-com/dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 to e2m122-pc
  Normal  Pulled     8m57s  kubelet            Container image "docker.io/istio/proxyv2:1.16.0" already present on machine
  Normal  Created    8m57s  kubelet            Created container istio-init
  Normal  Started    8m57s  kubelet            Started container istio-init
  Normal  Pulled     8m57s  kubelet            Container image "index.docker.io/kserve/router@sha256:e67364a8c9d3d78f0627195eb1945f3e1691f9cb7dd78f57f411fa92b5bce5bb" already present on machine
  Normal  Created    8m57s  kubelet            Created container user-container
  Normal  Started    8m57s  kubelet            Started container user-container
  Normal  Pulled     8m57s  kubelet            Container image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c" already present on machine
  Normal  Created    8m57s  kubelet            Created container queue-proxy
  Normal  Started    8m57s  kubelet            Started container queue-proxy
  Normal  Pulled     8m57s  kubelet            Container image "docker.io/istio/proxyv2:1.16.0" already present on machine
  Normal  Created    8m57s  kubelet            Created container istio-proxy
  Normal  Started    8m56s  kubelet            Started container istio-proxy

jagadeeshj/torchserve-kfs:0.7.0

Yes, you are right. I have mentioned the problem in the above comment.

@sivanantha321 Thanks for your information, however, the pytorch/torchserve-kfs:0.8.0 doesn't work with the current source code, thus I keep using the image: jagadeeshj/torchserve-kfs:0.7.0. However, when I try to request into the inference graph using pod forward (I couldn't follow the same way as denoted in the tutorial):
kubectl port-forward -n kubeflow-user-example-com pods/dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 8080:8080 --address=<IP_ADDRESS>
the response was:
*   Trying <IP_ADDRESS>:8080...
* TCP_NODELAY set
* Connected to <IP_ADDRESS> (<IP_ADDRESS>) port 8080 (#0)
> POST / HTTP/1.1
> Host: <IP_ADDRESS>:8080
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Length: 4269
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 500 Internal Server Error
< Date: Thu, 18 May 2023 07:27:25 GMT
< Content-Length: 43
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host <IP_ADDRESS> left intact

Pod's description:
kubectl describe pods/dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 -n kubeflow-user-example-com
Name:         dog-breed-pipeline-00001-deployment-5c998df47f-g8z62
Namespace:    kubeflow-user-example-com
Priority:     0
Node:         e2m122-pc/<IP_ADDRESS>
Start Time:   Thu, 18 May 2023 15:22:08 +0800
Labels:       app=dog-breed-pipeline-00001
              pod-template-hash=5c998df47f
              security.istio.io/tlsMode=istio
              service.istio.io/canonical-name=dog-breed-pipeline
              service.istio.io/canonical-revision=dog-breed-pipeline-00001
              serving.knative.dev/configuration=dog-breed-pipeline
              serving.knative.dev/configurationGeneration=1
              serving.knative.dev/configurationUID=de856a00-2c2c-4a48-9219-f0588992c68d
              serving.knative.dev/revision=dog-breed-pipeline-00001
              serving.knative.dev/revisionUID=ea9baed8-587c-4f4a-943d-d5ec4fde24f1
              serving.knative.dev/service=dog-breed-pipeline
              serving.knative.dev/serviceUID=71216221-0972-49fb-abaf-0b9ecb0bc51b
Annotations:  autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
              autoscaling.knative.dev/min-scale: 1
              container.seccomp.security.alpha.kubernetes.io/queue-proxy: runtime/default
              kubectl.kubernetes.io/default-container: user-container
              kubectl.kubernetes.io/default-logs-container: user-container
              prometheus.io/path: /stats/prometheus
              prometheus.io/port: 15020
              prometheus.io/scrape: true
              serving.knative.dev/creator: system:serviceaccount:kubeflow:kserve-controller-manager
              sidecar.istio.io/status:
                {"initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["workload-socket","credential-socket","workload-certs","istio-env...
Status:       Running
IP:           <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  ReplicaSet/dog-breed-pipeline-00001-deployment-5c998df47f
Init Containers:
  istio-init:
    Container ID:  containerd://5a2b97f2b89f6684d5ae30b983d339c93be4ef0ca75142d18def28819e70a95a
    Image:         docker.io/istio/proxyv2:1.16.0
    Image ID:      docker.io/istio/proxyv2@sha256:f6f97fa4fb77a3cbe1e3eca0fa46bd462ad6b284c129cf57bf91575c4fb50cf9
    Port:          <none>
    Host Port:     <none>
    Args:
      istio-iptables
      -p
      15001
      -z
      15006
      -u
      1337
      -m
      REDIRECT
      -i
      *
      -x

      -b
      *
      -d
      15090,15021,15020
      --log_output_level=default:info
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Thu, 18 May 2023 15:22:09 +0800
      Finished:     Thu, 18 May 2023 15:22:09 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:        10m
      memory:     40Mi
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
Containers:
  user-container:
    Container ID:  containerd://ad147f111c0e679f70f3fcc482e1d8896a31a07820123e6ff4953ab95b385095
    Image:         index.docker.io/kserve/router@sha256:e67364a8c9d3d78f0627195eb1945f3e1691f9cb7dd78f57f411fa92b5bce5bb
    Image ID:      docker.io/kserve/router@sha256:e67364a8c9d3d78f0627195eb1945f3e1691f9cb7dd78f57f411fa92b5bce5bb
    Port:          8080/TCP
    Host Port:     0/TCP
    Args:
      --graph-json
      {"nodes":{"root":{"routerType":"Sequence","steps":[{"name":"cat_dog_classifier","serviceName":"cat-dog-classifier","serviceUrl":"http://cat-dog-classifier.kubeflow-user-example-com.svc.cluster.local/v1/models/cat-dog-classifier:predict"},{"name":"dog_breed_classifier","serviceName":"dog-breed-classifier","serviceUrl":"http://dog-breed-classifier.kubeflow-user-example-com.svc.cluster.local/v1/models/dog-breed-classifier:predict","data":"$request","condition":"[@this].#(predictions.0==\"dog\")"}]}}}
    State:          Running
      Started:      Thu, 18 May 2023 15:22:09 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     1
      memory:  1Gi
    Requests:
      cpu:     100m
      memory:  100Mi
    Environment:
      PORT:             8080
      K_REVISION:       dog-breed-pipeline-00001
      K_CONFIGURATION:  dog-breed-pipeline
      K_SERVICE:        dog-breed-pipeline
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
  queue-proxy:
    Container ID:   containerd://d448564e22e1ba4e2ede69f609601b706e20e8699eea7c3d9e43f866d0e2ff20
    Image:          gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c
    Image ID:       gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c
    Ports:          8022/TCP, 9090/TCP, 9091/TCP, 8012/TCP, 8112/TCP
    Host Ports:     0/TCP, 0/TCP, 0/TCP, 0/TCP, 0/TCP
    State:          Running
      Started:      Thu, 18 May 2023 15:22:09 +0800
    Ready:          True
    Restart Count:  0
    Requests:
      cpu:      25m
    Readiness:  http-get http://:15020/app-health/queue-proxy/readyz delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:
      SERVING_NAMESPACE:                        kubeflow-user-example-com
      SERVING_SERVICE:                          dog-breed-pipeline
      SERVING_CONFIGURATION:                    dog-breed-pipeline
      SERVING_REVISION:                         dog-breed-pipeline-00001
      QUEUE_SERVING_PORT:                       8012
      QUEUE_SERVING_TLS_PORT:                   8112
      CONTAINER_CONCURRENCY:                    0
      REVISION_TIMEOUT_SECONDS:                 300
      REVISION_RESPONSE_START_TIMEOUT_SECONDS:  0
      REVISION_IDLE_TIMEOUT_SECONDS:            0
      SERVING_POD:                              dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 (v1:metadata.name)
      SERVING_POD_IP:                            (v1:status.podIP)
      SERVING_LOGGING_CONFIG:
      SERVING_LOGGING_LEVEL:
      SERVING_REQUEST_LOG_TEMPLATE:             {"httpRequest": {"requestMethod": "{{.Request.Method}}", "requestUrl": "{{js .Request.RequestURI}}", "requestSize": "{{.Request.ContentLength}}", "status": {{.Response.Code}}, "responseSize": "{{.Response.Size}}", "userAgent": "{{js .Request.UserAgent}}", "remoteIp": "{{js .Request.RemoteAddr}}", "serverIp": "{{.Revision.PodIP}}", "referer": "{{js .Request.Referer}}", "latency": "{{.Response.Latency}}s", "protocol": "{{.Request.Proto}}"}, "traceId": "{{index .Request.Header "X-B3-Traceid"}}"}
      SERVING_ENABLE_REQUEST_LOG:               false
      SERVING_REQUEST_METRICS_BACKEND:          prometheus
      TRACING_CONFIG_BACKEND:                   none
      TRACING_CONFIG_ZIPKIN_ENDPOINT:
      TRACING_CONFIG_DEBUG:                     false
      TRACING_CONFIG_SAMPLE_RATE:               0.1
      USER_PORT:                                8080
      SYSTEM_NAMESPACE:                         knative-serving
      METRICS_DOMAIN:                           knative.dev/internal/serving
      SERVING_READINESS_PROBE:                  {"tcpSocket":{"port":8080,"host":"<IP_ADDRESS>"},"successThreshold":1}
      ENABLE_PROFILING:                         false
      SERVING_ENABLE_PROBE_REQUEST_LOG:         false
      METRICS_COLLECTOR_ADDRESS:
      CONCURRENCY_STATE_ENDPOINT:
      CONCURRENCY_STATE_TOKEN_PATH:             /var/run/secrets/tokens/state-token
      HOST_IP:                                   (v1:status.hostIP)
      ENABLE_HTTP2_AUTO_DETECTION:              false
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
  istio-proxy:
    Container ID:  containerd://c1c49237b59ca98e62e83bcdc54c845c3e785e674084b4b0c8d8cf711e5a7a0e
    Image:         docker.io/istio/proxyv2:1.16.0
    Image ID:      docker.io/istio/proxyv2@sha256:f6f97fa4fb77a3cbe1e3eca0fa46bd462ad6b284c129cf57bf91575c4fb50cf9
    Port:          15090/TCP
    Host Port:     0/TCP
    Args:
      proxy
      sidecar
      --domain
      $(POD_NAMESPACE).svc.cluster.local
      --proxyLogLevel=warning
      --proxyComponentLogLevel=misc:error
      --log_output_level=default:info
      --concurrency
      2
    State:          Running
      Started:      Thu, 18 May 2023 15:22:10 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:     2
      memory:  1Gi
    Requests:
      cpu:      10m
      memory:   40Mi
    Readiness:  http-get http://:15021/healthz/ready delay=1s timeout=3s period=2s #success=1 #failure=30
    Environment:
      JWT_POLICY:                    third-party-jwt
      PILOT_CERT_PROVIDER:           istiod
      CA_ADDR:                       istiod.istio-system.svc:15012
      POD_NAME:                      dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 (v1:metadata.name)
      POD_NAMESPACE:                 kubeflow-user-example-com (v1:metadata.namespace)
      INSTANCE_IP:                    (v1:status.podIP)
      SERVICE_ACCOUNT:                (v1:spec.serviceAccountName)
      HOST_IP:                        (v1:status.hostIP)
      PROXY_CONFIG:                  {}

      ISTIO_META_POD_PORTS:          [
                                         {"name":"user-port","containerPort":8080,"protocol":"TCP"}
                                         ,{"name":"http-queueadm","containerPort":8022,"protocol":"TCP"}
                                         ,{"name":"http-autometric","containerPort":9090,"protocol":"TCP"}
                                         ,{"name":"http-usermetric","containerPort":9091,"protocol":"TCP"}
                                         ,{"name":"queue-port","containerPort":8012,"protocol":"TCP"}
                                         ,{"name":"https-port","containerPort":8112,"protocol":"TCP"}
                                     ]
      ISTIO_META_APP_CONTAINERS:     user-container,queue-proxy
      ISTIO_META_CLUSTER_ID:         Kubernetes
      ISTIO_META_INTERCEPTION_MODE:  REDIRECT
      ISTIO_META_WORKLOAD_NAME:      dog-breed-pipeline-00001-deployment
      ISTIO_META_OWNER:              kubernetes://apis/apps/v1/namespaces/kubeflow-user-example-com/deployments/dog-breed-pipeline-00001-deployment
      ISTIO_META_MESH_ID:            cluster.local
      TRUST_DOMAIN:                  cluster.local
      ISTIO_KUBE_APP_PROBERS:        {"/app-health/queue-proxy/readyz":{"httpGet":{"path":"/","port":8012,"scheme":"HTTP","httpHeaders":[{"name":"K-Network-Probe","value":"queue"}]},"timeoutSeconds":1}}
    Mounts:
      /etc/istio/pod from istio-podinfo (rw)
      /etc/istio/proxy from istio-envoy (rw)
      /var/lib/istio/data from istio-data (rw)
      /var/run/secrets/credential-uds from credential-socket (rw)
      /var/run/secrets/istio from istiod-ca-cert (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-c6bzq (ro)
      /var/run/secrets/tokens from istio-token (rw)
      /var/run/secrets/workload-spiffe-credentials from workload-certs (rw)
      /var/run/secrets/workload-spiffe-uds from workload-socket (rw)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  workload-socket:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  credential-socket:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  workload-certs:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  istio-envoy:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:     Memory
    SizeLimit:  <unset>
  istio-data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  istio-podinfo:
    Type:  DownwardAPI (a volume populated by information about the pod)
    Items:
      metadata.labels -> labels
      metadata.annotations -> annotations
  istio-token:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  43200
  istiod-ca-cert:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      istio-ca-root-cert
    Optional:  false
  kube-api-access-c6bzq:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   Burstable
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  8m58s  default-scheduler  Successfully assigned kubeflow-user-example-com/dog-breed-pipeline-00001-deployment-5c998df47f-g8z62 to e2m122-pc
  Normal  Pulled     8m57s  kubelet            Container image "docker.io/istio/proxyv2:1.16.0" already present on machine
  Normal  Created    8m57s  kubelet            Created container istio-init
  Normal  Started    8m57s  kubelet            Started container istio-init
  Normal  Pulled     8m57s  kubelet            Container image "index.docker.io/kserve/router@sha256:e67364a8c9d3d78f0627195eb1945f3e1691f9cb7dd78f57f411fa92b5bce5bb" already present on machine
  Normal  Created    8m57s  kubelet            Created container user-container
  Normal  Started    8m57s  kubelet            Started container user-container
  Normal  Pulled     8m57s  kubelet            Container image "gcr.io/knative-releases/knative.dev/serving/cmd/queue@sha256:505179c0c4892ea4a70e78bc52ac21b03cd7f1a763d2ecc78e7bbaa1ae59c86c" already present on machine
  Normal  Created    8m57s  kubelet            Created container queue-proxy
  Normal  Started    8m57s  kubelet            Started container queue-proxy
  Normal  Pulled     8m57s  kubelet            Container image "docker.io/istio/proxyv2:1.16.0" already present on machine
  Normal  Created    8m57s  kubelet            Created container istio-proxy
  Normal  Started    8m56s  kubelet            Started container istio-proxy

Yes, you are right. I have mentioned the problem in the above comment.


feat(core): play sound through Automation & ActionMqttPublish

The problem to solve
The action "play sound" needs more flexibility.
Some users are frustrated because it is not working as they would like, but I have different needs, so it is very hard, near impossible, to implement all. This is the perfect use case for Automation introduced recently.
Feature use case

control either the system should trigger sound or not.

more information in #14
in resume: I can receive information if somebody introduced in my courtyard when I watch TV without triggering my alarm. Imagine you have a child or so on...

Control which devices should make sound.

"I want to make sound only on the device that triggered the motion event".
"I want to make sound on every capable device".

Feature Proposal

Create Automation with two different triggers: (on_motion_left OR on_alarm_turn_off), or in reverse on_motion_detected.

[x] We need (on_motion_left OR on_alarm_turn_off) because the resident can turn off the Alarm and that cuts off the on_motion_left (won't be triggered). And of course if she's turn off the Alarm she expects to turn off the sound too.

Link MqttPublishAction to it.

[x] Be able to publish on a topic with the device_id so I can either control the sound on one device (the one that's concerned by the event) or every device with a speaker.
[x] Sound topic is designed to work with boolean and not JSON. We need to be able to publish boolean through mqtt, see PR #228

Warning
It is not user friendly, for example here my parents won't be able to configure this. In the future I might need to add a "preconfiguration" for sound management. During the installation I could select a scenario or somewhere else. I don't really know yet.

We cannot configure automations to run when alarm status changes (on/off).


Combining or chaining mappers

Is it possible to combine mappers. For example I want to use both title mapper:
+ (JSONKeyMapper *)keyMapper
{
    return [JSONKeyMapper mapperForTitleCase];
}

and key mapping:
+ (JSONKeyMapper *)keyMapper {
	return [[JSONKeyMapper alloc] initWithModelToJSONDictionary:@{
		@"id": @"orderId",
		@"productName": @"orderDetails.name",
		@"price": @"orderDetails.price.usd"
	}];
}

Yes, you just use a 'base mapper' - https://github.com/jsonmodel/jsonmodel/blob/master/JSONModel/JSONModelTransformations/JSONKeyMapper.h#L94

Or obviously you can just implement a block-based mapper: https://github.com/jsonmodel/jsonmodel/blob/master/JSONModel/JSONModelTransformations/JSONKeyMapper.h#L70
and just chain it within your code


Backport #10638

Backport #10638.

Hopefully the date placeholder is OK? Or how do we usually do that?

Quickly looking in the history
https://github.com/mne-tools/mne-python/commit/fa3b3efd1b5491ec6765c42dd0a7613f8eeba5e4#diff-1bb8964d625ff2f2c39c77c3e7f96231d129f57823202f98f8756079c78ffb59L21
Looks like (unreleased) is a good way to go

thx @cbrnr !


Serializing fails with non-struct output data

Issue with version: 0.9.0
This occurs with all commands that serialize to a primitive or an array.
For example:
$ ./tmc-langs-cli-x86_64-unknown-linux-gnu-0.9.0 disk-space --path ~/.
{
  "output-kind": "output-data",
  "status": "finished",
  "message": "Failed to convert OutputData(OutputData { status: Finished, message: \"calculated free disk space for partition containing /home/anon/.\", result: ExecutedCommand, data: Some(FreeDiskSpace(431909)) }) to JSON",
  "result": "error",
  "data": {
    "output-data-kind": "error",
    "kind": "generic",
    "trace": [
      "Caused by: Failed to convert OutputData(OutputData { status: Finished, message: \"calculated free disk space for partition containing /home/anon/.\", result: ExecutedCommand, data: Some(FreeDiskSpace(431909)) }) to JSON",
      "Caused by: cannot serialize tagged newtype variant Data::FreeDiskSpace containing an integer"
    ]
  }
}

I encountered the following error with 0.9.0 after authenticating with a previous version and trying core get-course-details:
[2021-01-26T11:26:43Z ERROR tmc_langs_cli::config::credentials] Failed to deserialize credentials.json due to "The process cannot access the file because another process has locked a portion of the file. (os error 33)", deleting

I encountered the following error with 0.9.0 after authenticating with a previous version and trying core get-course-details:
[2021-01-26T11:26:43Z ERROR tmc_langs_cli::config::credentials] Failed to deserialize credentials.json due to "The process cannot access the file because another process has locked a portion of the file. (os error 33)", deleting


Usage of web workers to accelerate critical processes

Is your feature request related to a problem? Please describe.
Currently performance is done on a single thread (main thread), and this may cause operation blocking and decrease performance.
Describe the solution you'd like
Create code that moves critical processes to a separate web worker, so that operations can be offloaded and multithreaded. Some critical processes include compile, render, and the directives.
Describe alternatives you've considered
We could also consider debouncing directives, kind of like a simplified concurrent mode for React.
Additional context
Inspiration: https://github.com/niutech/vue-in-web-worker

There wouldn't be much benefit of offloading compile, but we could look into splitting different stuff which uses different components into their own threads and post messages for state updates, not quite sure how well it would work with l-for. We would also have to force the state to be JSON so we could send it as a payload to the workers as a string.

Like if we had:

The responsibility of updating its text would be in it's own worker.

@shadowtime2000 That's a good point - we should try it out. I wonder if its too heavy on memory


pleb doesn't support monorepos with nested package structure

We tried implementing pleb for publishing our packages, and we saw that in our structure, which is not a flat packages structure, pleb fails locating the packages.
steps to reproduce:
git clone git@github.com:wixplosives/sample-monorepo.git ./test-pleb
cd test-pleb
# now we need to change the root package.json's workspaces field to "packages/**/*".
# after done that:
rm -rf packages
mkdir -p packages/test/test-package
cd packages/test/test-package
npm init -y
echo "console.log('hello world')">index.js

# this will locate that the package was never published
npx pleb publish --dry-run
cd ../../../

# this will not find the package
npx pleb publish --dry-run

Need to update the workspaces field in root package.json?

It looks the packages up using the "workspaces" field, just like npm or yarn would. It needs to point to the packages.

oh, just noticed the comment saying packages/**/*. that worked on npm/yarn, but not pleb?


Fix for event_system_properties description

Fixes Azure/azure-cli#21849
This PR has the fix for the event_system_properties description and an example to provide multiple system properties

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

kusto

@kairu-ms @yonzhan @jsntcy Could you review this PR once you get a chance ?

/azp run

BTW, if you went to release this update, you need to update the extension version and add release history.

@kairu-ms I didn't use any extensions as I did the changes directly from the github and created the Pull Request.

@kairu-ms @yonzhan @jsntcy Could you please merge this PR once you get a chance ? Awaiting your reply.


Silvercrest 3 Socket Power Strip - 3 Sockets all on or off.

I've installed a Silvercrest 3 Socket Power Strip on my Homey early 2016 version. Using the 0.22 version of the Lidl app. It created 3 tiles in the device overview as expected.
However i was surprised to see all turn on or off when i am switching 1 on or off.

Should be fixed in upcoming uptade.


Solve the slow consumer, subscription problem

Fixes https://github.com/Shopify/sarama/issues/1897

[x] Use ticks to flush new subscriptions.
[ ] Make the tick interval configurable for different use case.

Why is it needed?
Details in  https://github.com/Shopify/sarama/issues/1897
Slow consumers have high MaxProcessingTime.  If the subscription to all topics does not happen in the first flush to bc.newSubscriptons then due to high MaxProcessingTime the next subscription will only happen after 2 ticks of MaxProcessingTime. This makes the subscription very slow.
Instead if we flush based on time,  and the tick interval is configurable, then this works for both slow and fast consumer use cases. Works for consumer having short and longMaxProcessingTime
Please share a better approach to solve this if there can be.
cc @dim

@bai Please suggest if you agree with the solution. If yes, please suggest where can I add the flushTicker config to make it configurable for different use cases...
If you have a better solution in mind, please suggest.

@alok87 hmm, I read back through the linked issue and the debugging output that you posted a few times and looked over the PR, but I still don't understand how the proposed change would be beneficial in your scenario
I'll admit that I'm not familiar with this subscriptionManager aspect of the consumer code and I probably need to spend some time familiarising myself with what is currently there as well.
Can you describe how we might go about reproducing your issue locally?

@dnwe hey thanks for the response.
The issue happens only when the MaxProcessingTime for the consumer group is high (10mins for us).
Reproduced
I took out the part of the code to make it easier to debug and reproduce the issue.  Here is the code issue.go https://gist.github.com/alok87/5e9f960a7d376d72d8137793bdc9ad12
$ go run issue.go
I0315 17:40:06.656947   83310 issue.go:120] subscriptionConsumer(2) waiting
I0315 17:40:06.656972   83310 issue.go:67] subscriptionManager(2) STARTING FOR LOOP
I0315 17:40:06.657123   83310 issue.go:101] subscriptionManager(2) received ts.topic-0, buffer(1)
I0315 17:40:06.657131   83310 issue.go:91] subscriptionManager(2) bc.wait() stopped
I0315 17:40:06.657136   83310 issue.go:122] subscriptionConsumer(2) resuming...
I0315 17:40:06.657142   83310 issue.go:145] added subscription to 2/ts.topic-0
I0315 17:40:06.657146   83310 issue.go:136] subscriptionConsumer(2) waiting for acks wait()
I0315 17:40:06.657154   83310 issue.go:82] subscriptionManager(2) sent buffer(1), buffer set nil
I0315 17:40:07.657896   83310 issue.go:80] subscriptionManager(2) received ts.topic-1, buffer(2)
I0315 17:40:08.660548   83310 issue.go:80] subscriptionManager(2) received ts.topic-2, buffer(3)
I0315 17:40:09.662039   83310 issue.go:80] subscriptionManager(2) received ts.topic-3, buffer(4)
I0315 17:40:10.664217   83310 issue.go:80] subscriptionManager(2) received ts.topic-4, buffer(5)
I0315 17:40:11.665924   83310 issue.go:80] subscriptionManager(2) received ts.topic-5, buffer(6)
I0315 17:40:12.668347   83310 issue.go:80] subscriptionManager(2) received ts.topic-6, buffer(7)
I0315 17:40:13.672909   83310 issue.go:80] subscriptionManager(2) received ts.topic-7, buffer(8)
I0315 17:40:14.674409   83310 issue.go:80] subscriptionManager(2) received ts.topic-8, buffer(9)
I0315 17:40:15.675832   83310 issue.go:80] subscriptionManager(2) received ts.topic-9, buffer(10)
I0315 17:40:16.677863   83310 issue.go:62] producing done

In this example 10 topics need subscriptions. As soon as the first message(topic) was sent to bc.input the buffer got flushed for this single message.
Then the subscriptionConsumer routine got stuck at bc.acks.Wait since the consumer group is having huge MaxProcessingTime. This happens since the feeder loop sends acks.Done only when the ticker tick happens twice (20mins for us).
So till 20mins nothing new gets subscribed even when the buffer has many pending topics ready for subscriptions.
Ticking at 5 second interval started subscribing 200 topics for us in first flush, which works for us. But might need a different value for different use cases. But then I feel there can be a better way around this issue.
Please let me know if you need more details.

Possible to meet over zoom for this or do we have some team meeting for this project?
Wanted to explain the problem and discuss it. It is important to us.

👋🏻 sorry for not having got back to you on this, it is still on my TODO to revisit this PR soon

Sure.
But the issue is a real problem that we should look at. Not a concern for us now but the problem we found out since we went that path once.

@alok87 would you able to test the branch on https://github.com/Shopify/sarama/pull/2109 and confirm if that reworked subscription manager solves the issue for you?


.exe / binary release

I know it's not ready yet and in early dev, but you can keep this issue as a kind of reminder :)

https://nightly.link/Fabulously-Optimized/vanilla-installer-rust/workflows/build/main


[Feature Request] Go to Definition from the comments

In clangd we have some simple heuristics to provide Go to Definition for symbols mentioned in the comments. If there are structs/functions/<...> with he same name around the comment, we allow jumping to that symbol right from the comment. I find it really useful and it helps navigate the code faster, so it would be really nice to have something like this in rust-analyzer.
Ideally, this could be even more advanced than what we have in clangd since Rust does have a rich comment format that can actually reference symbols and provide better documentation. I've tried pressing gd on some of the type names in Rust Standard Library and in toy examples like the one I have below for clangd but nothing happened.
https://user-images.githubusercontent.com/3352968/140510608-bec099f1-7657-46eb-8109-c75e8a77454e.mov

This actually works sometimes, but it's a bit janky (sorry for the slightly chaotic recording):
https://user-images.githubusercontent.com/308347/140635131-c7d0ce71-6eba-4ea8-9282-c3dea1d319f9.mp4


Fix local dependency imports on Windows

Related #2208 (not 100% sure if it fixes the issue)

Need to add this to 2024-04 branch to be release, I will add another PR


After SHADE/SET/PALETTE, plots do not revert to default palette

Reported by Ansley B Manke on 16 Apr 2003 19:25 UTC
use etopo20
shade/x=75:110/y=0:20/palette=land_sea/set rose
ppl shade
shade rose   ! uses land_sea palette again.
Same for FILL command.  Happens for previous versions of
Ferret as well.  Maybe not a big deal, if it hasn't come
up before now.
Migrated-From: http://dunkel.pmel.noaa.gov/trac/ferret/ticket/534

Comment by<EMAIL_ADDRESS>on 21 Oct 2003 20:16 UTC
Moving from the<EMAIL_ADDRESS>user to the<EMAIL_ADDRESS>user.

Comment by<EMAIL_ADDRESS>on 6 Nov 2003 19:57 UTC
decrease priority level, reassign to Ansley


[BUG] OpenSearch should create _seq_no field mapping at Index creation itself and NOT after atleast 1 doc is ingested

Describe the bug
_seq_no field is not created by OpenSearch at index creation time. It seems to be created at the time of ingestion of 1 st document for that index
When our plugin (Security Analytics) fetches data from an index, it tries to sort by _seq_no which fails on empty index instead of returning empty result.
Related component
Indexing
To Reproduce

Create index
Before ingesting data, search on index with sort field as _seq_no
3.Error shows up

Caused by: org.opensearch.index.query.QueryShardException: No mapping found for [_seq_no] in order to sort on
        at org.opensearch.search.sort.FieldSortBuilder.resolveUnmappedType(FieldSortBuilder.java:564) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.search.sort.FieldSortBuilder.build(FieldSortBuilder.java:411) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.search.sort.SortBuilder.buildSort(SortBuilder.java:168) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.search.SearchService.parseSource(SearchService.java:1268) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.search.SearchService.createContext(SearchService.java:998) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.search.SearchService.executeQueryPhase(SearchService.java:606) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.search.SearchService$2.lambda$onResponse$0(SearchService.java:579) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.action.ActionRunnable.lambda$supply$0(ActionRunnable.java:74) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.action.ActionRunnable$2.doRun(ActionRunnable.java:89) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:52) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.threadpool.TaskAwareRunnable.doRun(TaskAwareRunnable.java:78) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:52) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.common.util.concurrent.TimedRunnable.doRun(TimedRunnable.java:59) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.common.util.concurrent.ThreadContext$ContextPreservingAbstractRunnable.doRun(ThreadContext.java:913) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at org.opensearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:52) ~[opensearch-3.0.0-SNAPSHOT.jar:3.0.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
        at java.lang.Thread.run(Thread.java:1583) ~[?:?]

### Expected behavior

OpenSearch should use a protected index template that defines metadata mappings like _version, _seq_no for all indices at index createion time itself

### Additional Details

_No response_

When our plugin (Security Analytics) fetches data from an index, it tries to sort by _seq_no which fails on empty index instead of returning empty result.

@eirsep can't this be handled in plugin ? any specific use case on why we do this query ?

[Triage attendees - 1 2 3 4]


Release/0.3.5

Basics

[ ] I added a line to changelog.md
[ ] The PR is rebased with current master.
[ ] Details of what you changed are in commit messages.
[ ] References to issues, e.g. close #X, are in the commit messages and changelog.
[ ] The buildserver is happy.

Checklist

[ ] I have installed and I am using pre-commit hooks
[ ] I fully described what my PR does in the documentation
[ ] I fixed all affected documentation
[ ] I fixed the introduction tour
[ ] I wrote migrations in a way that they are compatible with already present data
[ ] I fixed all affected decisions
[ ] I added automated tests or a manual test protocol
[ ] I added code comments, logging, and assertions as appropriate
[ ] I translated all strings visible to the user
[ ] I mentioned every code or binary not directly written or done by me in reuse syntax
[ ] I created left-over issues for things that are still to be done
[ ] Code is conforming to our Architecture
[ ] Code is conforming to our Guidelines
[ ] Code is consistent to our Design Decisions
[ ] Exceptions to any guidelines are documented

Review

[ ] I've tested the code
[ ] I've read through the whole code
[ ] I've read through the whole documentation
[ ] I've checked conformity to guidelines

We can permanently enable the external link checker now, I put the links that are causing problems to the exclude config.

We could permanently enable the link checker, I added the problematic links to the exlude config. But now jenkins has some TLS problems:

Yes, because of that it is probably still better to only run it manually.

You can merge and release this. :rocket:


Possibility to choose primary domain (with-www or without-www) and redirect from one to the other

Feature request: Possibility to choose primary domain (with-www or without-www) and redirect from one to the other. Could be added as a --www and --nonwww flags.

There are four possibilities:

Command
Domain

ee site create example.com
http://example.com

ee site create www.example.com
http://www.example.com

ee site create example.com --le
https://example.com

ee site create www.example.com --le
https://www.example.com

What we need

[ ] Whenever somebody runs a command with --le the remaining three options should redirect to the primary domain specified in the executed command
[ ] Whenever somebody runs a command without --le i.e. just for plain HTTP site, the other version, www or non-www should redirect to the primary domain specified in the executed command

@rahul286 Yeah, that's a very good breakdown

What about adding alias domains like:
ee site create example.com example.de --le
Should I make a separate feature request for that?

@michacassola yep. We would like to defer it. We want to get v4 out asap.

Ok, heres the issue: https://github.com/EasyEngine/easyengine/issues/1033

Fixed in https://github.com/EasyEngine/site-command/pull/70


Cannot seed and download from same Node.js process?

So I have a Node.js file where I start seeding a file with client1 and create a client2 that downloads it using a magnet URI. I hardcoded the torrentPort for client1 to 20001 so that it doesn't conflict with client2.
The download doesn't seem to work for some reason. However if I repeat the process but comment out the client1 download part and instead download the file using the webtorrent client from another shell session, it downloads correctly.
Is there anything in the code that might explain this? I recall seeing refusing handshake with self errors in the logs. Is this a bug related to the fact that both clients share the same node process?
Both clients have different peerIds/nodeIds.
Here's part of the log output:
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm addPeer <IP_ADDRESS>:20001
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm:peer new Peer <IP_ADDRESS>:20001
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm tcp connect attempt to <IP_ADDRESS>:20001
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm:peer Peer <IP_ADDRESS>:20001 connected
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm:peer new Peer ::ffff:<IP_ADDRESS>:51646
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm:peer Peer ::ffff:<IP_ADDRESS>:51646 connected
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm _addIncomingPeer ::ffff:<IP_ADDRESS>:51646
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm:peer destroy ::ffff:<IP_ADDRESS>:51646 (error: refusing to handshake with self)
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm removePeer ::ffff:<IP_ADDRESS>:51646
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm:peer destroy <IP_ADDRESS>:20001 (error: undefined)
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm removePeer <IP_ADDRESS>:20001
Tue, 27 Oct 2015 09:20:27 GMT bittorrent-swarm conn <IP_ADDRESS>:20001 closed: will not re-add (max 3 attempts)

<IP_ADDRESS> being my IP.

Well, this is not really a priority so closing.

@olalonde Yeah I think this is due to the bittorrent-swarm package using the same listening port for both clients. I think this might have been fixed in the last month or two, but I can't remember.


osv.dev  search by Repo URL

Is your feature request related to a problem? Please describe.
It's confusing / frustrating that you can't search by repo URL, especially for ecosystemless adivisories, which the only way to identify the package, is by repo URL. It also shows up under Packages in the vulnerability list, so allowing search keeps it consistent.

Describe the solution you'd like
Search indices should be also populated by repo URL (with and without scheme, and maybe each segment in the repo URL?).
E.g. for repourl https://github.com/MariaDB/server
search_indicies should also have https://github.com/MariaDB/server, github.com/MariaDB/server, MariaDB, server

@aidoskanapyanov this one may be challenging to work on without an instance of OSV.dev running on GCP, so it may not be the best first issue for an external contributor. Feel free to sample the others, or if you want to try and spin up an instance of OSV.dev on your own GCP project, that would be a good test of the ability for an external contributor to do so...


Eslint false positive errorrs

Description
I have some error using native LSP in Neovim. I don't have any of those Using Eslint in Webstorm, VSCode or using Ale or COC

Neovim version
NVIM v0.7.0
Build type: Release
LuaJIT 2.1.0-beta3
Nvim-lspconfig version
No response
Operating system and version
macOS 12.3.1
Affected language servers
eslint
Steps to reproduce
It's a complex monorepo, looks like eslint uses a wrong config or something like this.
I don't know from what to start troubleshooting however with some help I'm ready to do any checks would be necessary to prevent potential error like this on the future.
Actual behavior

Expected behavior
No errors
Minimal config
local lspconfig = require("lspconfig")
lspconfig.eslint.setup({})

LSP log
https://gist.github.com/Arelav/33c8813ca5b87e36ba22d57518ff19c3

Could compare the server config that is sent by nvim lsp client, vs the others. Should be in the logs somewhere.

2022-07-03T20:46:04.984 INFO (pid:93788) [plugin] - coc.nvim initialized with node: v16.14.2 after 34ms 2022-07-03T20:46:07.670 ERROR (pid:93788) [core-editors] - document not found for window: 1000 2022-07-03T20:46:09.606 INFO (pid:93788) [services] - registered service "eslint" 2022-07-03T20:46:09.607 INFO (pid:93788) [services] - ESLint state change: stopped => starting 2022-07-03T20:46:09.662 INFO (pid:93788) [services] - ESLint state change: starting => running 2022-07-03T20:46:09.665 INFO (pid:93788) [services] - service eslint started 2022-07-03T20:46:17.765 INFO (pid:93788) [attach] - receive notification: openLog []
This is coc-eslint enabled and logged through :CocOpenLog not much useful info.

It maybe related when using global installed eslint vs local. Not the version difference but perhaps it takes a different config
I see something similar when trying Doom Emacs.

I use Fish shell. Today I migrated from fundle to Fisher and this maybe a reason or maybe vim plugins where updated.
Bottom line it works as supposed to be now.

One more thing changed is after brew upgrade neovim version was changed from 7.0 to 7.2
I hope it will help somebody with the same issues.


feat: bump near-sdk to 5.1.0

Strangely check Rust Contracts / Tests (pull_requests) was skipped after approving workflows to run, even though relevant files where changed since the last run. It didn't tell why so I just started it manually through Github's UI.

I missed 542009b was pushed while I was reviewing. Will have to take a look at that before enabling merge.

@mitinarseny what is the motivation for adding 542009b to this PR?

I've just tried to use near-plugins in another project and it turns out that it doesn't let you use #[derive(AccessControlRole)], #[access_control], etc... without importing indirect trait dependencies into current scope:
use near_plugins::{access_control, AccessControlRole, AccessControllable, Ownable, Pausable};

#[derive(AccessControlRole, Clone, Copy)]
pub enum Role {
    // ...
}

#[access_control(role_type(Role))]
pub struct Contract {
    // ...
}

But I agree that it's not directly connected to "bumping near-sdk version".
@mooori Do you think it would be better to fix it in a separate PR?

PS: I might need to rebase the whole branch to have my commits signed... Do you mind if I do it now and re-request your review? Sorry for that, didn't pay attention in the first place

I want to avoid the force push and re-review, so I've disabled this requirement.

Thank you so much! @mooori @karim-en 🙏🏻
Waiting for merge from someone with write access
PS: Already set up everything related to commit signing, so wouldn't mess up in the next PR😅


BUG: Sketch constructor arg for user should be args.user not args.use

Small typo here https://github.com/amzn/sketch-constructor/blob/v1.4.1/models/Sketch/Sketch.js#L53
user: new User(args.use),
should be
user: new User(args.user),

@SebastianFlo Since it's a small bug, do you mind putting up a PR for this?

:tada: This issue has been resolved in version 1.4.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Failed attempt to update Neo4J.rb with devise-neo4j

Appearing error is:
D:\Dev\Quantum>jruby -S bundle update
Updating git://github.com/andreasronge/neo4j.git
Updating git://github.com/andreasronge/devise-neo4j.git
Updating git://github.com/pmq20/mathjax-rails.git
Fetching source index for http://rubygems.org/
Bundler could not find compatible versions for gem "neo4j":
  In Gemfile:
    devise-neo4j (>= 0) java depends on
      neo4j (~> 1.1) java

    neo4j (2.0.0.alpha.1)

The part of my gemfile is following:
gem 'rails'
gem 'neo4j', :git => 'git://github.com/andreasronge/neo4j.git'
gem 'devise-neo4j', :git => 'git://github.com/andreasronge/devise-neo4j.git'
gem "carrierwave-neo4j", :require => "carrierwave/neo4j"
gem 'mathjax-rails', :git => 'git://github.com/pmq20/mathjax-rails.git'

When we release neo4j 2.0.0 we have to make sure that the devise-neo4j will depend on 2.0.0
I think devise-neo4j still work with the latest. If you really want to use the latest neo4j from github then I suggest forking devise-neo4j and updating the gem dependency to neo4j 2.0.0

Thanks a lot Andreas! I'll be waiting for release ;) Good day friends! :)


Ego-Vehicle in IDM-Vehicle transformiert - Review changes

We discussed all the changes and created a road map for the future.


Move @jpwesselink to Emeriti

Moves @jpwesselink to CommComm Emeriti, with his permission via private message.

Going to merge this and submit the PR to email aliases. 👍

Ref for email PR: https://github.com/nodejs/email/pull/73


dictionary iframes can steal focus from lute

Is your feature request related to a problem? Please describe.
I have a dictionary, en.openrussian.org, when opened in lute, it steals focus.
This makes changing word status annoying.
I click on a word, then try to hit a number, but the iframe has stolen the focus (it sets it to an input element), and so typing the number changes the input text.
Describe the solution you'd like
the iframe should not steal focus
Describe alternatives you've considered
na
Additional context
I have a fix locally for this.
Instead of calling activate straightaway, i call activate after the iframe's load event has fired.
This way the iframe can't steal focus on load (since it has display none, until we call activate)
It works pretty well for my use case and I can't see that it would negatively impact other iframe dictionaries.
Happy to write a PR.

Hi there, thanks for the issue!  I think someone already has a PR for this from a few days ago I need to test and merge.  Will close this if so. Cheers!

Hi @s-cork , PR #459 actually dealt with this issue already, so I'll close this one.  Thank you again!

Launched in 3.5.1.


模型训练遇到问题

模型开始训练时遇到如下问题，是输入数据大小不一致的原因吗
File "/opt/miniconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/_utils/worker.py", line 287, in _worker_loop
data = fetcher.fetch(index)
File "/opt/miniconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/_utils/fetch.py", line 47, in fetch
return self.collate_fn(data)
File "/home/glodon/.local/lib/python3.7/site-packages/mmcv/parallel/collate.py", line 81, in collate
for key in batch[0]
File "/home/glodon/.local/lib/python3.7/site-packages/mmcv/parallel/collate.py", line 81, in
for key in batch[0]
File "/home/glodon/.local/lib/python3.7/site-packages/mmcv/parallel/collate.py", line 84, in collate
return default_collate(batch)
File "/opt/miniconda3/envs/open-mmlab/lib/python3.7/site-packages/torch/utils/data/_utils/collate.py", line 56, in default_collate
return torch.stack(batch, 0, out=out)
RuntimeError: stack expects each tensor to be equal size, but got [3, 66, 102] at entry 0 and [3, 400, 125] at entry 1

请按照 issue 模版进行提问，并提供其中要求的信息

已经解决，感谢

已经解决，感谢

🎉

@qiu-pinggaizi  如何解决的？通过padding吗？


MNT: rerender

Hi! This is the friendly automated conda-forge-webservice.
I've rerendered the recipe as instructed in #26.
Here's a checklist to do before merging.

[ ] Bump the build number if needed.

Fixes #26

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Looks like one of the macOS tests failed on CI. Tried restarting in case it was transient, but it still fails. Attached the logs as well for posterity.

Done in PR ( https://github.com/conda-forge/make-feedstock/pull/25 )


JavaDocs for Crafting System Methods

Description
Task: Add Javadocs to all Crafting System methods.
Feature: Optimisation and Enhancement of Crafting System + Additional Features
To improve documentation of code for future reference Javadocs will be added for every single method created by the crafting system.
Milestones
List of steps that need to be completed for this task.

[x] Finish all Javadocs (Oct. 10)

Completion Deadline: Oct. 10
Member

Rohan Kollambalath(@rkoll55 )

Finished all javadocs


Add possibility to start typed event streams with non-generic StartStream

I have a use case where I'm starting new event streams without knowing the type at compile time. It's essential for me that the stream type info gets persisted. This change declares two new StartStream methods on the IEventStore interface which allows you to pass the the aggregate type as a parameter.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: scrodde sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.

@oskardudycz will do!

I added an additional overload to keep consistency and updated documentation.

@scrodde congratulations. You just become 103 Marten contributor 😃

haha, thx @oskardudycz ;)


Checking Cactbot update in ACT fail

When checking cactbot update in ACT, it shows this error message, have tried clean install and ACT again but it still persists.

This functionality (despite saying cactbot) is part of OverlayPlugin.  Can you file a bug on https://github.com/ngld/OverlayPlugin/ instead?

I got the same update error too.

I went ahead and opened the issue on the OP github
https://github.com/ngld/OverlayPlugin/issues/263

For people still having this issue, you may be using an outdated version of the Overlay Plugin. The Github address of the Overlay plugin was recently changed from ngld/OverlayPlugin to OverlayPlugin/OverlayPlugin., and ACT is not updating it automatically. You will need to deinstall the old plugin from ACT and install it again.

This should be fixed with the new OverlayPlugin.


Ability to specify zero accounts created/unlocked

Expected Behavior
I would like to be able to specify zero accounts created/unlocked when starting ganache.
Current Behavior
Setting options = { total_accounts: 0 } does not work as it will default to 10 accounts if set to 0 due to this line: https://github.com/trufflesuite/ganache-core/blob/develop/lib/statemanager.js#L42.
Context
I am trying to test situations where a user signs out of MetaMask. If a user goes from a logged-in state to a logged-out state in MetaMask, the web3 object persists in the browser but the number of unlocked accounts available goes to zero. I would like to be able to test this behaviour in my code.

@jstoxrocky I know it's been a long time since you've open the issue (sorry about that!). If the user specifies no accounts there can't be a coinbase account --  which is the account that mines the blocks. I was thinking we could just use the 0x0 account as the default coinbase account.
Do you have any thoughts?

work for this in #817


Blog post about the use of Yaml2Text to encode ModSpec instances

As requested in https://github.com/metanorma/metanorma-ogc/issues/493

Thank you @manuelfuenmayor !


⚠ Bofrost.at has degraded performance

In 14b929c, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 938 ms

Resolved: Bofrost.at performance has improved in d040844.


Fixes #318 includes/excludes for dependencies

Fixex #318

I implemented all your review comments, time for another try?

@stefanseifert  any remarks for it?

any news on this?
I'd be happy to make further changes...

Pleas squash to final one commit.

...squashed


floor(0) returns "-1"

Thank you for great library!
Today I got an issue, so please let me share.
const value = floor(
  interpolate(progress, {
    inputRange: [0, 1],
    outputRange: [0, 0],
    extrapolate: Extrapolate.CLAMP,
  }),
)
// value === -1
const value = round(
  interpolate(progress, {
    inputRange: [0, 1],
    outputRange: [0, 0],
    extrapolate: Extrapolate.CLAMP,
  }),
)
// value === 0

value should be Animated.Node<0> but will be Animated.Node<-1> somehow.
Is this the specification? or bug?
I'm sorry if this is expected result!
I'm using Expo SDK33.
iPhoneSE version 12.1.4
Expo Client.
yarn.lock
react-native-reanimated "1.0.1"

Thank you in advance!

block([
  debug('progress: ', progress),
  debug('progress: ', floor(progress)),
  ...
])

was out put following
progress:  0
progress:  -1
progress:  3.2072777779897055
progress:  3
progress:  4.0962977774937945
progress:  4
progress:  4.9852955547968545
progress:  4
progress:  5.874086666107178
progress:  5
progress:  6.763024444580078
progress:  6
progress:  7.652097776730855
progress:  7
progress:  8.541193332672119
progress:  8
progress:  9.430057776769003
progress:  9
progress:  10.31898222287496
progress:  10
progress:  11.207986666361492
progress:  11

round() function @ objective-c will round value like this.
That's why this happen.
floor() function works fine anyway.
  int logInt1 = round(0.5); // 1
  NSLog(@"%d" , logInt1);
  logInt1 = round(-0.5);    // -1
  NSLog(@"%d" , logInt1);
  logInt1 = round(-1.5);    // -2
  NSLog(@"%d" , logInt1);

https://github.com/kmagiera/react-native-reanimated/blob/master/src/derived/floor.js
So, this file - 0.5 is introduce this result :D

I can confirm this issue (ios only). Thanks for the report @ken0x0a !


AWS External resource label matching fails

Thanks for a great project! It's given us great insights. But I have a question: How can we get AWS external resource tagging to work? We're trying to get Department to work. We've followed the guide at https://guide.kubecost.com/hc/en-us/articles/4407596810519-AWS-Out-of-Cluster-
In General settings, we've set up "Department Label" to "app.kubernetes.io/part-of",
Our k8s resources have the label app.kubernetes.io/part-of: winter-road-insights.
Our S3 bucket has the tag kubernetes_label_app.kubernetes.io/part-of	winter-road-insights
And if we check the "Assets" page for the bucket, it shows up with "kubernetes_label_app_kubernetes_io_part_of=winter-road-insights" (see screenshot)
But on the "Cost allocation" page, when sorting by Department, only the k8s resources show up. External shows as 0. Is there anything we should change?

@jonerer I'm going to close this and work through the ticket created via Slack. If this turns out to be a bug we will create a new github issue.


No Zeal mapping for java on salesforce apex class

I'm using the MavensMate Sublime Text plugin to develop for the Salesforce platform. When pressing F1 Zeal throws an error stating "No Zeal mapping found for java language".
For some reason Zeal thinks its a Java file, not Apex file.

One workaround is having this on your settings:
"language_mapping": {
    "Apex": {"lang": "apex", "zeal_lang": "apex"},
    "Java": {"lang": "java", "zeal_lang": "apex"},
    "Visualforce": {"lang": "visualforce", "zeal_lang": "visualforce"},
    "HTML": {"lang": "html", "zeal_lang": "visualforce"}
}

However, this would override the real html and java syntax


Speed up packfile iterator when specific type

If specified, the packfile decoder only decode objects of a specific type, improving the decoding time in this cases.

Added public constructor, NewPackfileIter, to be able to iterate objects of a specific type into a packfile in a low level way.
Modified the Decoder to be able to read object headers first, to only decode specific objects.

Current coverage is 76.13% (diff: 86.36%)

Merging #200 into master will decrease coverage by 0.58%

@@             master       #200   diff @@
==========================================
  Files            96         96
  Lines          6224       6252    +28
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           4775       4760    -15
- Misses          923        972    +49
+ Partials        526        520     -6

Powered by Codecov. Last update 133b97e...96aa6de

@ajnavarro  Please, use the appropiate title for the commit and PR (first package, then message, lowercase).


Wrong exit code returned

Hi, I'm still debugging this issue, but it seems like the wct cli command is returning an error code 0 instead of 1 when a test fails.
I've added a few console.logs:
Test run ended in failure: 1 failed tests
hook: cleanup

firefox 45 (4/0/1)

process.exit 0

The process.exit(0) is called in https://github.com/Polymer/web-component-tester/blob/master/bin/wct#L21
I'm using Node 6.4.0, npm 3.10.3 and running in a Docker container created by image specified here: https://github.com/MartinsThiago/polymer-tester
(Note that I'm currently just running /bin/bash and running the tests that way to investigate the issue).
I can also reproduce this on Mac OS X El Capitan and the same Node/npm versions.
I'm using<EMAIL_ADDRESS>and the issue persists with 4.4.0-prerelease.1.

Can confirm, taking a look now.

PR out, hope to merge soon.

Fixed by v4.3.4

Thanks for the bug report!

Thanks for the quick response 👍, I can confirm the fix worked.


Updating environment variable name for mongodb with the new one for Heroku

Updating environment variable name for mongodb with the new one for Heroku (according to https://devcenter.heroku.com/articles/mongolab)
Fixes #1411

LGTM

LGTM.

:+1:

I looked into this a little further, and realized that this might not be a necessary change. Just as long as the name used on Heroku's environment config settings matches up with what our application uses, then there shouldn't be a problem. If someone is using Heroku's MongoDB plugin, then there may be a mismatch if they don't set an environment variable that matches the name that our framework uses.
My concern here is that we can't account for every variation of naming convention that's used by all possible deployment environments. For instance, what if AWS uses a different name for their MongoDB connection strings?
To me the name we use is irrelevant, and it's up to the developer to configure their app to accommodate whichever environment they are deploying to; to ensure their MEANJS app matches up with their deployment environment.

@mleanos I understand what you're trying to say but we aren't accommodating every possible config, but rather just herokus, and they indeed changed their config variable from the old one to the new one so I don't see an issue here. (I also validated with other repositories performed this change)
Unless you really think there's something else to consider here I don't see why not to make this change.

@lirantal I'm fine with this change. I just wanted to express my point of view.  To me there isn't an impact if we do, or do not, make this change. So lets roll with this to keep our naming consistent with Heroku's.

Cool, merging.


Hide the General section nav if it's empty

Right now, even if you have no fields in the General section, the section name and link appear in the Navbar. This PR hides the General section if it's empty, and redirects to the first available section (if possible).
Before

After

This is awesome, its the little things sometimes!


Switch .post() and .put() to .create() and .update()

This one has been a long time coming: POSTing a post to the posts endpoint is a linguistic nightmare, and HTTP verbs are part of the API interface that is best kept away from the users.
This alters all of the existing GET, POST, PUT, DELETE and HEAD methods to be (semi)private and prefixed by _http, e.g. _httpDelete: The public interfaces for these (.get, .create, .update, .delete and .headers).
.post and .put are maintained for the time being for back-compat but will be removed in 1.0.

After broadcasting this to the WCEU community, to anybody who comes to chime in: can you articulate

whether you prefer the HTTP or semantic English verbs; and
do you think the HTTP equivalents should be removed?

Good chat. Provisionally merging, will see what feedback is like in tomorrow's presentation.


feat: Track of events checklist

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.758%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
122

Relevant Lines:
162

💛  - Coveralls


Maximum direct response body size

Description
Hello, can someone please explain why is the direct response body limited explicitly to 4096B? See https://github.com/envoyproxy/envoy/blob/master/source/common/router/config_utility.cc#L114
I would like to be at least able to change this value.
Thank you.

Because Envoy reads this file into memory and does not have any capability to efficiently serve from disk. I have no issue with making this value configurable.

@sekaninat I think the question is answered, I'm closing this. Feel free to re-open it if you need further clarifications.

If anyone else gets here, it was closed in #13422, max_direct_response_body_size_bytes in RouteConfiguration.


arm: mpu: Unify ARM_MPU kconfig definitions

Previously, there were two separate Kconfig definitions of ARM_MPU located at:

arch/arm/core/mpu/Kconfig
arch/arm64/core/cortex_r/Kconfig

This lead to incomplete default settings and unexpected missing configurations.
This commit combines the two into a single unified definition now located at arch/common/Kconfig to prevent this.

@carlocaione Is it ok to add ARM_* things in arch/Kconfig ?
An alternative could be to have all in arch/arm/ and then split on A/R/M, 32/64bits and v6/7/8 but that would require A LOT more changes.