KServe CloudEvents infinite-loop using Knative Eventing Broker
See original GitHub issue/kind bug
What steps did you take and what happened:
We’re using Knative eventing Broker
and Trigger
with a filter for triggering the PredictHandler
handler in a custom model server using KServe python library.
Currently, KServe python library sends the response CloudEvent with the same attributes from the original CloudEvent and there is no option to filter the response CloudEvent to avoid the infinite-loop of CloudEvents being sent to KServe from the Broker
.
What did you expect to happen:
We expect to at least change the response CloudEvent source
field to KServe instance name or some env variable.
Anything else you would like to add: Line of problematic code: https://github.com/kserve/kserve/blob/464308defb7245110a3dbf255629d7f418bb9947/python/kserve/kserve/handlers/http.py#L99
Environment:
- Istio Version: 1.11.4
- Knative Version: 1.0
- KFServing Version: 0.7
- Kubeflow version: N/A
- Kfdef: N/A
- Minikube version: N/A
- Kubernetes version: (use
kubectl version
): 1.21.2 - OS (e.g. from
/etc/os-release
): Amazon Linux 2
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (6 by maintainers)
Top GitHub Comments
@shahar3012 I made a PR here https://github.com/kserve/kserve/pull/1934
@shahar3012 Including the KFModel name in the
source
seems like a good idea. I’ll also maketype
source
configurable with env vars. And probably an env var to merge attributes if desired (except id, timestamp, source, type)I’ll make some changes, fix the tests and create a PR soon.