diff options
| author | Dante Niewenhuis <d.niewenhuis@hotmail.com> | 2024-11-05 18:41:50 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-11-05 18:41:50 +0100 |
| commit | 15730a89974e10fb19e689c0379a7e761fba0c14 (patch) | |
| tree | e84f19ce13358841ac14e7840d8c2bf823a72a51 /site/docs/advanced-guides/architecture.md | |
| parent | 0f835d57b0e989e25aa0b71fe374a0fb1a94e86f (diff) | |
Hiding all tutorials that are currently not working to reduce confusion (#263)
* Hidden all tutorials that are currently not working to reduce confusion
* removed advanced guides from docusaurus
* removed advanced guides from whats-next
* removed advanced guides from support page
Diffstat (limited to 'site/docs/advanced-guides/architecture.md')
| -rw-r--r-- | site/docs/advanced-guides/architecture.md | 26 |
1 files changed, 0 insertions, 26 deletions
diff --git a/site/docs/advanced-guides/architecture.md b/site/docs/advanced-guides/architecture.md deleted file mode 100644 index 2a65a6c6..00000000 --- a/site/docs/advanced-guides/architecture.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -sidebar_position: 2 ---- - -# Architecture - -OpenDC consists of four components: a Kotlin simulator, a SQL database, a Quarkus-based -[API](https://github.com/atlarge-research/opendc/tree/master/opendc-web/opendc-web-api), and a -React.js [frontend](https://github.com/atlarge-research/opendc/tree/master/opendc-web/opendc-web-api). - - - -On the frontend, users can construct a topology by specifying a datacenter's rooms, racks and machines, and create -scenarios to see how a workload trace runs on that topology. The frontend communicates with the web server via a REST -API over HTTP. - -The (Swagger/OpenAPI compliant) API spec specifies what requests the frontend can make to the web server. To view this -specification, go to the [Swagger Editor](https://editor.swagger.io/) and paste in -our [API spec](https://api.opendc.org/q/openapi). - -The web server receives API requests and processes them in the database. When the frontend requests to run a new -scenario, the web server adds it to the `scenarios` collection in the database and sets its `state` as `PENDING`. - -The simulator monitors the database for `PENDING` scenarios, and simulates them as they are submitted. The results of -the simulations are processed and aggregated in memory. Afterwards, the aggregated summary is written to the database, -which the frontend can then again retrieve via the web server. |
