|
1 |
| -# DevStream Architecture Summary |
| 1 | +# DevStream Architecture Overview |
2 | 2 |
|
3 |
| -This document summarizes the main components of DevStream and how data and requests flow between these components. |
| 3 | +This document summarizes the main components of DevStream and how data flows between these components. |
4 | 4 |
|
5 |
| -## DevStream Request Flow |
| 5 | +## 0. Data Flow |
6 | 6 |
|
7 | 7 | The following diagram shows an approximation of how DevStream executes a user command:
|
8 | 8 |
|
9 | 9 | 
|
10 | 10 |
|
11 |
| -## CLI (The `devstream` Package) |
| 11 | +There are three major parts: |
12 | 12 |
|
13 |
| -For simplicity, the CLI is named `dtm` instead of the full name DevStream. |
| 13 | +- CLI: handles user input, commands and parameters |
| 14 | +- plugin engine: achieves the core functionalities by calling other modules (config loader, plugins manager, etc.) |
| 15 | +- plugins: implements the actual install/uninstall for a certain DevOps tool |
14 | 16 |
|
15 |
| -Every time a user runs the `dtm` program, the execution transfers immediately into one of the "command" implementations in the [`devstream`](https://github.com/merico-dev/stream/tree/main/cmd/devstream) package, in which folder all commands' definitions reside. Then, each command calls the corresponding package under [`internal/pkg`](https://github.com/merico-dev/stream/tree/main/internal/pkg). |
| 17 | +## 1. CLI (The `devstream` Package) |
16 | 18 |
|
17 |
| -The flow illustrated above applies to the main DevStream commands like `dtm install`, `dtm uninstall` (_TODO_), and `dtm reinstall` (_TODO_). For these commands, the role of the command is to parse all the config, load each plugin, and call the [predefined interface](https://github.com/merico-dev/stream/blob/main/internal/pkg/plugin/plugin.go#L12). |
| 19 | +Note: for simplicity, the CLI is named `dtm`(DevOps Tool Manager) instead of the full name DevStream. |
18 | 20 |
|
19 |
| -## Configuration Loader |
| 21 | +Every time a user runs the `dtm` program, the execution transfers immediately into one of the "command" implementations in the [`devstream`](https://github.com/merico-dev/stream/tree/main/cmd/devstream) package, in which folder all commands' definitions reside. |
20 | 22 |
|
21 |
| -Model types in package [`config`](https://github.com/merico-dev/stream/blob/main/internal/pkg/config/config.go) represent the top-level configuration structure. |
| 23 | +Then, each command calls the plugin engine package under [`internal/pkg`](https://github.com/merico-dev/stream/tree/main/internal/pkg/pluginengine). |
22 | 24 |
|
23 |
| -## State Manager |
| 25 | +The plugin engine calls the config loader first to read the local YAML config file into a struct. |
24 | 26 |
|
25 |
| -_TODO_ |
| 27 | +Then it calls the plugin manager to download the required plugins. |
26 | 28 |
|
27 |
| -## Plugin Engine |
| 29 | +After that, the plugin engine calls the state manager and plan manager to create a plan. At last, the plugin engine asks the plan manager to execute the plan and the state manager to update the state. During the execution of the plan, the plugin engine loads each plugin (*.so file) and calls the predefined interface. |
| 30 | + |
| 31 | +## 2. Plugin Engine |
28 | 32 |
|
29 | 33 | The plugin engine has various responsibilities:
|
30 | 34 |
|
31 |
| -- making sure the required plugins (according to the config) are present (_TODO_) |
32 |
| -- generate a plan according to the state (_TODO_) |
| 35 | +- making sure the required plugins (according to the config) are present |
| 36 | +- generate a plan according to the state |
33 | 37 | - execute the plan by loading each plugin and running the desired operation
|
34 | 38 |
|
35 |
| -_Note: there will be a rework of the engine to generate and execute a plan according to the state manager, which hasn't been implemented yet._ |
| 39 | +It achieves the goal by calling the following modules: |
| 40 | + |
| 41 | +### 2.1 Configuration Loader |
| 42 | + |
| 43 | +Model types in package [`config`](https://github.com/merico-dev/stream/blob/main/internal/pkg/configloader/config.go#L12) represent the top-level configuration structure. |
| 44 | + |
| 45 | +### 2.2 Plugin Manager |
| 46 | + |
| 47 | +The [plugin manager](https://github.com/merico-dev/stream/blob/main/internal/pkg/pluginmanager/manager.go) is in charge of downloading necessary plugins according to the configuration. |
| 48 | + |
| 49 | +If a plugin with the desired version already exists locally, it will not download it again. |
36 | 50 |
|
37 |
| -## Plugins |
| 51 | +### 2.3 State Manager |
| 52 | + |
| 53 | +The [state manager](https://github.com/merico-dev/stream/blob/main/internal/pkg/statemanager/manager.go) manages the "state", i.e., what has been done successfully and what not. |
| 54 | + |
| 55 | +### 2.4 Plan Manager |
| 56 | + |
| 57 | +The [plan manager](https://github.com/merico-dev/stream/blob/main/internal/pkg/planmanager/plan.go) creates a plan according to the state and the config and executes the plan. |
| 58 | + |
| 59 | +## 3. Plugins |
38 | 60 |
|
39 | 61 | A _plugin_ implements the aforementioned predefined interfaces.
|
40 | 62 |
|
41 |
| -It executes operations like install, reinstall (_TODO_), uninstall (_TODO_), and stores state (_TODO_). |
| 63 | +It executes operations like install, uninstall, and stores state. |
| 64 | + |
| 65 | +To develop a new plugin, see [creating_a_plugin.md](https://github.com/merico-dev/stream/blob/main/docs/creating_a_plugin.md). |
0 commit comments