Updated README.md to match the current codebase

README.md

@@ -35,7 +35,9 @@ In **nexus-server**'s root directory, we find three directories:
 
 - `bin` where binaries reside
 - `config` where configuration files reside
-- `data` where templates, VMs and temporary files reside
+- `data/templates` where VM templates reside
+- `data/vms` where VMs reside
+- `data/tmp` folder where temporary files are created (and deleted)
 
 Here is the filesystem hierarchy for a system featuring one template and one VM:
 
@@ -119,13 +121,13 @@ Templates are typically disk images of various OS users might want to create VMs
 - Alpine
 - etc.
 
-There are two types of templates:
+Templates can be `public` or `private`:
 
-- `public` templates which are visible to everyone
-- `private` templates which are only visible to the user who created it
+- `public` templates are visible to everyone
+- `private` templates are only visible to their owner (the user who created them)
 
 VMs disks are based on templates. Each VM uses its own disk which is an overlay pointing to a template (base) disk image.
-Hence, each VM only stores the differences from the template image. This scheme allows to save tremendous disk space.
+Hence, each VM only stores the differences from the template image. This scheme allows to save a tremendous amount of disk space.
 
 ### Templates layout
 
@@ -133,10 +135,10 @@ Each template is uniquely identified by a UUID (version 4) and resides in its ow
 
 A template directory contains the following files:
 
-- `template.json` is the template's configuration
-- `disk.qcow` is the template's disk image in QCOW2 format
+- `template.json`: the template's configuration
+- `disk.qcow`: the template's disk image in QCOW2 format
 
-The `template.json` file defines the ID of the template, its name, its owner, the access type which can either be `public` or `private`, and its creation time:
+The `template.json` file defines template'ID, its name, its owner, its access type (`public` or `private`), and its creation time:
 
 ```{.json}
 {
@@ -161,19 +163,19 @@ data
 
 A VM is made out of two files, a config file and a disk file:
 
-- `vm.json` describes the VM's configuration (ID, name, RAM, CPUs, template, user accesses)
+- `vm.json` describes the VM's configuration (ID, name, RAM, CPUs, owner, template, access)
 - `disk.qcow` is the disk image that defines the VM's "physical disk"
 
 The ID of a VM is a unique UUID (version 4).
-VMs are stored in `data/vms`. Each VM resides in its own directory.
+VMs are stored in `data/vms` and each VM resides in its own directory.
 
-Each VM config files (`vm.json`) is stored in a 3-directory-deep file hierarchy, where:
+Each VM has its own unique folder named after its UUID. This folder contains the VM config (`vm.json`) and disk image (`disk.qcow`). Each VM's folder resides in a 3-directory-deep file hierarchy, where:
 
 - 1st level directory is characters [0-2] of the VM UUID (4096 directories max)
 - 2nd level directory is characters [3-5] of the VM UUID (4096 directories max)
 - 3rd level directory is the full VM UUID
 
-For instance, the VM with ID `39d431f2-bf92-4e82-b26d-d597bc1c8142` is stored as:
+As an example, the VM with ID `39d431f2-bf92-4e82-b26d-d597bc1c8142` is stored as:
 
 ```{.shell}
 data
@@ -194,19 +196,9 @@ Here is the content of `vm.json`:
     "cpus": 2,
     "ram": 4096,
     "nic": "none",
+    "owner": "janedoe@nexus.org",
     "templateID": "12e064f2-2092-428e-9685-f3e573c18802",
     "access": {
-        "janedoe@nexus.org" : {
-            "VM_LIST":1,
-            "VM_START":1,
-            "VM_STOP":1,
-            "VM_REBOOT":1,
-            "VM_DESTROY":1,
-            "VM_EDIT":1,
-            "VM_SET_ACCESS":1,
-            "VM_READFS": 1,
-            "VM_WRITEFS": 1,
-        },
         "lukeskywalker@force.net" : {
             "VM_LIST":1,
             "VM_START":1,
@@ -220,8 +212,7 @@ Here is the content of `vm.json`:
 }
 ```
 
-When the VM is created, an external snapshot of its template is created in the VM directory under the name `disk.qcow`.
-The VM, therefore, only stores differences from the template.
+When the VM is created, an external snapshot of its template is created in the VM directory under the name `disk.qcow`. Thus, the VM's disk only stores differences from the template the VM is based on.
 
 ### VM creation
 
@@ -265,8 +256,8 @@ Consequently, it is highly recommended to install it in all templates as it give
 Access control is implemented through capabilities.
 Capabilities define what users can or cannot do. They are divided into two categories:
 
-- **User capabilities**: define user access control; these are stored in the user metadata
-- **VM access capabilities**: define access to VMs; these are stored in the VM metadata
+- **User capabilities**: define user access control; these are stored in the user config
+- **VM access capabilities**: define access to VMs; these are stored in the VM config
 
 ### User capabilities
 
@@ -320,17 +311,11 @@ These capabilities are called "VM access capabilities":
 | VM_READFS     | User can export files from the VM                                  |
 | VM_WRITEFS    | User can import files into the VM                                  |
 
-#### IMPORTANT
-
-- When a user creates a VM, she/he is **automatically granted all VM access capabilities**.
-- No other users is granted any access to the created VM. However, the VM owner can add any access type to any users they like.
-
-### Use cases
+### IMPORTANT
 
-- Many profs (who can create VMs) create private VMs
-- Many profs (who can create VMs) create many VMs for students parts of various classes
-- A prof must access/control their students' VMs
-- A student must see all her VMs (across different profs/classes)
+- When a user creates a VM, she/he is this VM's owner
+  - the owner is granted all VM access capabilities
+- No other users is granted any access to the created VM. However, the VM owner can add any access type to any users they like
 
 ## REST API