-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathtask.yaml
195 lines (169 loc) · 7.67 KB
/
task.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
swagger: "2.0"
info:
version: "1.0.0"
title: "Kids First Release Coordinator Task Service"
description: |
## Task Service
A task service runs a function that is a step in the release process
such as: Rolling over version numbers, updating file states for download,
and making new data visible to users. These tasks should expose a common
interface for the Coordination Service to communicate with. A task service
should implement the endpoints in this specification in order for the
release coordinator to properly invoke tasks.
## Task Sequence of Operations
Below is a basic overview of a task's expected sequence of operations and its states. See the sequence diagram \<link here\> for a detailed specification of the interaction between the Coordinator Service and a Task Service.
1) Receive `initialize` action from coordinator and move to `pending` state. Respond to coordinator with state set to `pending`. This is important since the coordinator will not send the `start` action until all tasks within the release are in `pending` state.
2) Receive `start` action from coordinator and move to `running` state. Respond to coordinator with state set to `running`.
3) (Optional) Update coordinator with current progress as the task does its work.
4) Complete processing and change state from `running` to `staged`
5) Update coordinator with current state. This is import since the coordinator will not send the `publish` action until all tasks within the release have sent a request with state set to `staged`.
6) Recieve `publish` from coordinator and run final actions to make data public
## Authentication
To ensure that a request to the task service originates from the coordinator, all requests to the task services will be made with a `Authorization` header containing a bearer jwt for ego.
This token may be used to verify the coordinator's identity against ego using the `/oauth/token/verify` endpoint.
license:
name: "Apache 2.0"
url: "http://www.apache.org/licenses/LICENSE-2.0.html"
host: "kids-first.io"
basePath: "/"
schemes:
- "http"
paths:
/status:
get:
summary: "Get information or health status of service"
description: |
Returns information about the Task service including the current
status. This endpoint is used by the Coordinator to determine the health
of the task service. Any non-200 response will imply that the service
is unavailable. If enough consective non-200 responses
are recieved by the Coordinator, then any tasks that may have been issued to the task service
will be assumed as failed.
operationId: "getStatus"
consumes:
- "application/json"
produces:
- "application/json"
responses:
200:
description: "Service ok"
schema:
$ref: "#/definitions/Status"
503:
description: "Service unavailable"
schema:
$ref: "#/definitions/Status"
/tasks:
post:
summary: "Task RPC action"
description: |
The Release Coordinator will use this endpoint to communicate all actions (via POSTs) that the task service must take during the release publish.
When a release is begun, the Release Coordinator service will send a POST to this endpoint with an `initialize` action. The task service should set its state to `pending` and respond with a status code 200.
The Coordinator will expect a 200 response from all task services in the release to continue with the release process.
If any non-200 response is returned, the Coordinator will cancel the release.
Once the Coordinator has verified that all tasks are ready for work,
it will signal the task service to begin staging data via a POST with action set to `start`.
Upon receiving the `start` action, the task service should begin staging the data and set it's state to `running`.
During the staging process the Release Coordinator will poll the task service for status via a POST and action set to `get_status`.
The task service should respond with its latest `state` and `progress`.
If any non-200 response is returned, the Coordinator will cancel the release. Once work is completed, the task should set its state to `staged` and task service should notify the Coordinator with its new state.
When its time for the data release to be made public, the Coordinator will signal the task service to begin publishing via a POST to this endpoint with action set to `publish`.
Upon receiving the `publish` action, the task service should set it's state to `publishing`.
Once again, the Release Coordinator will poll the task service for status via a POST and action set to `get_status`.
If any non-200 response is returned, the Coordinator will cancel the release.
If a task ever needs to be explicitly stopped at any point in time due to a failure of any kind, the task service may set its state to `failed`.
If the release is ever halted due to an explicit stop or because
of a failure in any task, the Coordinator will issue a `cancel`
action to all task services informing them to stop their task or discard any operations.
To summarize, the possible actions in a POST to this endpoint are:
- `initialize`
- `start`
- `publish`
- `get_status`
- `cancel`
The possible states of a task are:
- `pending` - Recieved the `initialize` action, but waiting for `start`
- `running` - After `start` action while the task is processing
- `staged` - After completing work
- `publishing` - While publicizing work
- `published` - After successfully publishing
- `canceled` - Task was canceled by coordinator
- `failed` - Task failed at some stage
operationId: "taskAction"
consumes:
- "application/json"
produces:
- "application/json"
parameters:
- in: "body"
name: "body"
description: "Task action"
required: true
schema:
$ref: "#/definitions/TaskAction"
responses:
200:
description: "Task accepted"
schema:
$ref: "#/definitions/Task"
503:
description: "Task rejected"
400:
description: "Invalid ID supplied"
404:
description: "Task not found"
definitions:
Status:
properties:
name:
description: "name of the service"
example: "datamodel rollover"
type: "string"
message:
description: "status message"
example: "ready for work"
type: "string"
version:
description: "Task service version number"
example: "2.0.4"
type: "string"
Task:
properties:
name:
type: "string"
format: "string"
example: "data model rollover"
kf_id:
type: "string"
format: "string"
example: "TA_3G2409A2"
release_id:
type: "string"
format: "string"
example: "RE_AB28FG90"
state:
type: "string"
format: "string"
example: "running"
progress:
type: "string"
format: "string"
example: "50%"
date_submitted:
type: "string"
format: "date"
example: "2018-03-19T20:12:24.702813+00:00"
TaskAction:
properties:
action:
type: "string"
format: "string"
example: "start"
task_id:
type: "string"
format: "string"
example: "TA_3G2409A2"
release_id:
type: "string"
format: "string"
example: "RE_AB28FG90"