|
|
|
Home page of the Floki prototype project |
|
|
\ No newline at end of file |
|
|
|
Home page of the Floki prototype project
|
|
|
|
|
|
|
|
## Proposed options
|
|
|
|
### User application and its Forwarding Agent within the same pod
|
|
|
|
|
|
|
|
Pros:
|
|
|
|
- Both processes can see each other via `localhost` requests
|
|
|
|
- Both processes can share the same `emptyDir` volume
|
|
|
|
|
|
|
|
Cons:
|
|
|
|
- On workflow deploy tools like Argo workflows, the dependencies between tasks are based on the result of the task (`.Succeeded`, `.Failed`, `.Errored`, `.Daemoned`, etc..)
|
|
|
|
- We'd like to spawn the next tasks based on the status of the main `User application` container, not after its execution
|
|
|
|
|
|
|
|
- Flow control over `User Application` execution status
|
|
|
|
- If User Application and Forwarding Agent are launched within the same pod, we'd like to control the flow based on the User Application status
|
|
|
|
- Can the Forwarding Agent act as a health check of the main process?
|
|
|
|
|
|
|
|
### User application and its Forwarding Agent on different pods
|
|
|
|
|
|
|
|
Pros:
|
|
|
|
- We can define dependencies between Forwarding Agents and other tasks instead of between current tasks
|
|
|
|
|
|
|
|
Cons:
|
|
|
|
- In Argo workflows we are still constrained by the result of a task; we can't spawn new task until its dependencies have finished |
|
|
\ No newline at end of file |
