summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorFabian Mastenbroek <mail.fabianm@gmail.com>2022-04-04 14:39:14 +0200
committerFabian Mastenbroek <mail.fabianm@gmail.com>2022-04-04 14:39:14 +0200
commit2d763eb569e041d27a84e9102a9c08fe0bcd4683 (patch)
tree9cadd1c690c81381f8e84f9039dc54c93090f990
parent1d3a76ac4e8de0af33454db9bb76853dbcca30f1 (diff)
docs: Update global architecture of OpenDC
This change updates the document outlining the architecture of OpenDC, which does not use a Python-based web API anymore.
-rw-r--r--docs/architecture.md20
1 files changed, 9 insertions, 11 deletions
diff --git a/docs/architecture.md b/docs/architecture.md
index 7e644ec1..c4609ae9 100644
--- a/docs/architecture.md
+++ b/docs/architecture.md
@@ -1,23 +1,21 @@
# Architecture
-OpenDC consists of four components: a Kotlin simulator, a MongoDB database, a Python
-Flask [API](/opendc-web/opendc-web-api), and a React.js [frontend](/opendc-web/opendc-web-ui).
+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).
![OpenDC Component Diagram](./images/component-diagram.png)
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 over
-SocketIO, through a custom REST request/response layer. For example, the frontend might make a `GET` request
-to `/api/v1/users/{userId}`, but this request is completed via SocketIO, not plain HTTP requests. Note that the API
-itself can also be accessed by HTTP.
+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 [opendc-api-spec.yml](../opendc-api-spec.yml).
+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 `QUEUED`.
+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 `QUEUED` 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.
+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.