From 2d763eb569e041d27a84e9102a9c08fe0bcd4683 Mon Sep 17 00:00:00 2001 From: Fabian Mastenbroek Date: Mon, 4 Apr 2022 14:39:14 +0200 Subject: 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. --- docs/architecture.md | 20 +++++++++----------- 1 file 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. -- cgit v1.2.3