summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorjc0b <j@jc0b.computer>2020-06-30 19:21:20 +0200
committerFabian Mastenbroek <mail.fabianm@gmail.com>2020-08-24 19:44:39 +0200
commitcf02cfc00efd664b79289fb867eed536656ac132 (patch)
tree359fd4581e5e8bc7850897568eaed4f6f9afbd99
parent6345841e9e53cb1543bd85577acf0c814a2b607e (diff)
parent61baf441680953b3d6fa47be0a69309570548fa4 (diff)
Merge branch 'feature/mongodb-migration' of github.com:atlarge-research/opendc-dev into feature/mongodb-migration
-rw-r--r--README.md50
-rw-r--r--misc/artwork/opendc-component-diagram.pngbin11875 -> 39965 bytes
-rwxr-xr-xmongodb/configure.sh23
3 files changed, 26 insertions, 47 deletions
diff --git a/README.md b/README.md
index 6a5a7f9c..eed60765 100644
--- a/README.md
+++ b/README.md
@@ -17,25 +17,25 @@ Users can construct datacenters (see above) and define experiments to see how th
![opendc-frontend-simulation](misc/artwork/opendc-frontend-simulation.png)
-The simulator is accessible both as a ready-to-use website hosted by Delft University of Technology at [opendc.org](http://opendc.org), and as source code that users can run locally on their own machine.
+The simulator is accessible both as a ready-to-use website hosted by Delft University of Technology at [opendc.org](https://opendc.org), and as source code that users can run locally on their own machine.
OpenDC is a project by the [@Large Research Group](http://atlarge-research.com).
## Architecture
-OpenDC consists of four components: a Kotlin simulator, a MariaDB database, a Python Flask web server, and a React.js frontend.
+OpenDC consists of four components: a Kotlin simulator, a MongoDB database, a Python Flask web server, and a React.js frontend.
<p align="center">
<img src="misc/artwork/opendc-component-diagram.png" alt="OpenDC Component Diagram">
</p>
-On the frontend, users can construct a topology by specifying a datacenter's rooms, racks and machines, and create experiments 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.
+On the frontend, users can construct a topology by specifying a datacenter's rooms, racks and machines, and create experiments 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.
-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 UI](http://petstore.swagger.io/) and "Explore" [opendc-api-spec.json](https://raw.githubusercontent.com/tudelft-atlarge/opendc/master/opendc-api-spec.json).
+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).
-The web server receives API requests and processes them in the SQLite database. When the frontend requests to run a new experiment, the web server adds it to the `experiments` table in the database and sets is `state` as `QUEUED`.
+The web server receives API requests and processes them in the database. When the frontend requests to run a new experiment, the web server adds it to the `experiments` table in the database and sets is `state` as `QUEUED`.
-The simulator monitors the database for `QUEUED` experiments, and simulates them as they are submitted. It writes the resulting `machine_states` and `task_states` to the database, which the frontend can then again retrieve via the web server.
+The simulator monitors the database for `QUEUED` experiments, and simulates them as they are submitted. It writes the resulting `machine_states` to the database, which the frontend can then again retrieve via the web server.
## Setup
@@ -43,7 +43,7 @@ The simulator monitors the database for `QUEUED` experiments, and simulates them
The official way to run OpenDC is using Docker. Other options include building and running locally, and building and running to deploy on a server.
-For all of these options, you have to create a Google API Console project and client ID, which the OpenDC frontend and web server will use to authenticate users and requests. Follow [these steps](https://developers.google.com/identity/sign-in/web/devconsole-project) to make such a project. In the 'Authorized JavaScript origins' field, be sure to add `http://localhost:8081` as origin. Download the JSON of the OAuth 2.0 client ID you created from the Credentials tab, and specifically note the `client_id`, which you'll need to build OpenDC.
+For all of these options, you have to create a Google API Console project and client ID, which the OpenDC frontend and web server will use to authenticate users and requests. Follow [these steps](https://developers.google.com/identity/sign-in/web/sign-in) to make such a project. In the 'Authorized JavaScript origins' and 'Authorized redirect URI' fields, be sure to add `http://localhost:8081` and `https://localhost:3000`. Download the JSON of the OAuth 2.0 client ID you created from the Credentials tab, and specifically note the `client_id`, which you'll need to build OpenDC.
### Installing Docker
@@ -53,6 +53,8 @@ Users of Windows 10 Home and previous editions of Windows can use [Docker Toolbo
#### Port Forwarding
+_Skip this if you have GNU/Linux, Mac OS X and Windows 10 Professional._
+
Open VirtualBox, navigate to the settings of your default docker VM, and go to the 'Network' tab. There, hidden in the 'Advanced' panel, is the 'Port forwarding' feature, where you can set a rule for exposing a port of the VM to the host OS. Add one from guest IP `10.0.2.15` to host IP `127.0.0.1`, both on port `8081`. This enables you to open a browser on your host OS and navigate to `http://localhost:8081`, once the server is running.
### Running OpenDC
@@ -61,36 +63,36 @@ To build and run the full OpenDC stack locally on Linux or Mac, you first need t
```bash
# Clone the repo and its submodules
-git clone --recursive https://github.com/atlarge-research/opendc.git
+git clone https://github.com/atlarge-research/opendc.git
# Enter the directory
cd opendc/
-
-# If you're on Windows:
-# Turn off automatic line-ending conversion in the simulator sub-repository
-cd opendc-simulator/
-git config core.autocrlf false
-cd ..
```
-In the directory you just entered, you need to set up a small configuration file. To do this, create a file called `keys.json` in the `opendc` folder. In this file, simply replace `your-google-oauth-client-id` with your `client_id` from the OAuth client ID you created. For a standard setup, you can leave the other settings as-is.
-
-```json
-{
- "FLASK_SECRET": "This is a super duper secret flask key",
- "OAUTH_CLIENT_ID": "your-google-oauth-client-id",
- "ROOT_DIR": "/opendc",
- "SERVER_BASE_URL": "http://localhost:8081"
-}
+In the directory you just entered, you need to set up a set of environment variables. To do this, create a file called `.env` in the `opendc` folder. In this file, replace `your-google-oauth-client-id` with your `client_id` from the OAuth client ID you created and put the path of this `opendc` folder in the place of `/your/path/to/opendc`. For a standard setup, you can leave the other settings as-is.
+
+```.env
+MONGO_INITDB_ROOT_USERNAME=root
+MONGO_INITDB_ROOT_PASSWORD=rootpassword
+MONGO_INITDB_DATABASE=admin
+OPENDC_DB=opendc
+OPENDC_DB_USERNAME=opendc
+OPENDC_DB_PASSWORD=opendcpassword
+OPENDC_FLASK_SECRET="This is a secret flask key, please change"
+OPENDC_OAUTH_CLIENT_ID=your-google-oauth-client-id
+OPENDC_ROOT_DIR=/your/path/to/opendc
+OPENDC_SERVER_BASE_URL=http://localhost:8081
```
+If you plan to publicly deploy, please also tweak the other settings. In that case, also check the `docker-compose.yml` for further instructions.
+
Now, start the server:
```bash
# Build the Docker image
docker-compose build
-# Start the OpenDC container and the database container
+# Start the containers
docker-compose up
```
diff --git a/misc/artwork/opendc-component-diagram.png b/misc/artwork/opendc-component-diagram.png
index 4aa535b9..312ca72a 100644
--- a/misc/artwork/opendc-component-diagram.png
+++ b/misc/artwork/opendc-component-diagram.png
Binary files differ
diff --git a/mongodb/configure.sh b/mongodb/configure.sh
deleted file mode 100755
index 78f28ac8..00000000
--- a/mongodb/configure.sh
+++ /dev/null
@@ -1,23 +0,0 @@
-if [ -z "$OPENDC_DB" ]; then
- echo "OPENDC_DB environment variable not specified"
- exit 1
-fi
-
-if [ -z "$OPENDC_DB_USERNAME" ]; then
- echo "OPENDC_DB_USERNAME environment variable not specified"
- exit 1
-fi
-
-if [ -z "$OPENDC_DB_PASSWORD" ]; then
- echo "OPENDC_DB_PASSWORD environment variable not specified"
- exit 1
-fi
-
-MONGO_COMMAND="mongo $OPENDC_DB -u $OPENDC_DB_USERNAME -p $OPENDC_DB_PASSWORD --authenticationDatabase $OPENDC_DB"
-
-until eval $MONGO_COMMAND --eval 'db.getCollectionNames();' ; do
- echo "MongoDB is unavailable - sleeping"
- sleep 1
-done
-
-echo "MongoDB available"