Skip to content

Commit 55ab20f

Browse files
author
github-actions
committed
sync model docs: 2024-11-11T06:14:51Z
1 parent c3b3e6f commit 55ab20f

1 file changed

Lines changed: 80 additions & 0 deletions

File tree

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
<!-- page-title: Webhook -->
2+
3+
# Webhook
4+
5+
When an event happens (e.g. creating new model's version, deploy endpoint), we might want to trigger action in other services, Merlin provides a way this by triggering a webhook call.
6+
The webhook that will be called is configured per event type, and it could contain multiple endpoints which can be configured as synchronous or asynchronous call.
7+
8+
For the detail of available configuration please refer to [MLP library docs](https://github.com/caraml-dev/mlp/blob/main/api/pkg/webhooks/README.md), this documentation will only cover the basic config and the payload of webhook which we have implemented.
9+
10+
## 1. Webhook Configuration
11+
In Merlin's yaml for config you can add new field for the webhook's configuration which will looks like this:
12+
```yaml
13+
WebhooksConfig:
14+
Enabled: true
15+
Config:
16+
on-model-version-predeployment:
17+
- URL: http://127.0.0.1:8000/async-webhook
18+
Method: POST
19+
Async: true
20+
Name: async
21+
on-model-version-deployed:
22+
- URL: http://127.0.0.1:8000/async-webhook
23+
Method: POST
24+
Async: true
25+
Name: async
26+
on-model-version-undeployed:
27+
- URL: http://127.0.0.1:8000/sync-webhook
28+
Method: POST
29+
FinalResponse: true
30+
Name: sync
31+
```
32+
## 2. Webhook Events and Payload
33+
### 2.1. Model Version's Endpoint
34+
**Events:**
35+
- `on-model-version-predeployment`: will be triggered before the version endpoint is deployed, we will only proceed with the deployment if the webhook return a `200` response, otherwise if the webhook return is a non `200` response, the deployment will be **aborted**. In both case, we will not take into account of the response body, we will only look at the response code.
36+
- `on-model-version-deployed`: will be triggered after the version endpoint is successfully deployed (either new or updated), there will be no side effect if the webhook return a success or error response, we will only log the response if an error occurred.
37+
- `on-model-version-undeployed`: will be triggered after the version endpoint is successfully undeployed, there will be no side effect if the webhook return a success or error response, we will only log the response if an error occurred.
38+
39+
**Request Payload**
40+
```json
41+
{
42+
"event_type": "{event type}",
43+
"version_endpoint": "{version endpoint object}"
44+
}
45+
```
46+
47+
Examples:
48+
```json
49+
{
50+
"event_type": "on-model-version-predeployment",
51+
"version_endpoint": {
52+
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
53+
"version_id": 0,
54+
"status": "pending",
55+
...
56+
}
57+
}
58+
```
59+
60+
For the complete field of `version_endpoint` please refer to our [swagger docs](../../../../swagger.yaml).
61+
62+
**Response**
63+
64+
As of writing this document (25 September 2024) and mentioned previously, the successful response will not affect the process of our deployment. But for future usage, we're expecting the response of the final synchronous webhook that will be called to be in the following format:
65+
66+
Successful Response:
67+
```json
68+
{
69+
"code": "200",
70+
"version_endpoint": "{version endpoint object}"
71+
}
72+
```
73+
74+
Error response:
75+
```json
76+
{
77+
"code": "{error code}",
78+
"message": "{reason for error}"
79+
}
80+
```

0 commit comments

Comments
 (0)