diff options
| author | Fabian Mastenbroek <mail.fabianm@gmail.com> | 2022-09-13 17:28:57 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2022-09-13 17:28:57 +0200 |
| commit | ff7dfda051e0103b0df453473eb0f08cdc37ae85 (patch) | |
| tree | 2e80525809ecb5afe010faa99898ca479965b95a /docs/architecture.md | |
| parent | fde9ba4fb88bada9d9873ba21904e9e1a66b0c46 (diff) | |
| parent | fd208941622cd559a0c3a196a0754a1b33db402b (diff) | |
merge: Add documentation using Docusaurus (#97)
This pull request implements the new OpenDC documentation website using Docusaurus 2.
## Implementation Notes :hammer_and_pick:
* Add initial Docusaurus website.
* Migrate existing docs to Docusaurus.
* Configure Prettier for Docusaurus.
* Add tutorials to OpenDC website (#28)
* Add deployment workflow via GitHub actions
## External Dependencies :four_leaf_clover:
* Docusaurus 2
Closes #28
Diffstat (limited to 'docs/architecture.md')
| -rw-r--r-- | docs/architecture.md | 21 |
1 files changed, 0 insertions, 21 deletions
diff --git a/docs/architecture.md b/docs/architecture.md deleted file mode 100644 index c4609ae9..00000000 --- a/docs/architecture.md +++ /dev/null @@ -1,21 +0,0 @@ -# Architecture - -OpenDC consists of four components: a Kotlin simulator, a SQL database, a Quarkus-based -[API](/opendc-web/opendc-web-api), and a React.js [frontend](/opendc-web/opendc-web-ui). - - - -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. |