-You can also add an application logo if you want users to see one during authentication
-An application logo can be added so that users can see it during authentication
- Once created, keep note of the OAuth App Client ID & Secret; this secret is only temporarily available on GitHub... keep a copy in a safe place!
- If you need to generate a new secret the MEC Sandbox will have to be updated accordingly
- If a new secret is to be generated, the MEC Sandbox will have to be updated accordingly
5. Python Installation
- Install Python2:
- Ubuntu 18.04: `sudo apt install python-minimal`
@@ -79,7 +79,7 @@ This deployment configuration will require two VMs, see [Prerequisites](#prerequ
- Set uid & gid
-**NOTE:** Values of _uid_ and _gid_ can be obtained by using `id <username>` command on the VM
- Set _repo.deployment.ingress.host_ to FQDN (or VM IP)
-**NOTE:** In the absence of FQDN, TLS certificates can be disabled by setting the _repo.deployment.ingress.https-only_ to _false_ and _repo.deployment.ingress.ca_ to _self-signed_ or _none_
-**NOTE:** In the absence of FQDN (i.e. for local deployment), TLS certificates can be disabled by setting the _repo.deployment.ingress.https-only_ to _false_ and _repo.deployment.ingress.ca_ to _self-signed_ or _none_
- Set Thanos compactor retention times
- Overwrite repocfg file with provided long-term storage repocfg:
-**NOTE:** If different versions of AdavantEDGE are installed, when switching from one version to another, the command 'meepctl config gitdir' shall be executed to update the AdvantEDGE folder location
-**NOTE:** If different versions of AdavantEDGE are installed then when switching from one version to another, the command `meepctl config gitdir` shall be executed to update the AdvantEDGE folder location
- Deploy dependency pods:
-`meepctl deploy dep`
- Deploy Core pods:
-`meepctl deploy core`
-**NOTE:** Core pods deployment will only install the cert-manager rules to trigger certificate installation
- Run `kubectl get pods -A` to see if all pods are up and running correctly
- Run `kubectl get pods -A` to see if all the pods are up and running correctly
5. Log In & Create buckets:
- Using a browser, access the long-term storage VM via its FQDN or IP address
- Sign in using the provisioned credentials (access key & secret key)
@@ -149,7 +149,7 @@ This deployment configuration will require two VMs, see [Prerequisites](#prerequ
- Set UID and GID in _repo.deployment.ingress.permissions_ (usually 1000 or 1001 on Ubuntu)
-**NOTE:** Values of _uid_ and _gid_ can be obtained by using `id <username>` command on the VM
- Set _repo.deployment.ingress.host_ to VM FQDN (or IP address)
-**NOTE:** In the absence of FQDN, TLS certificates can be disabled by setting the _repo.deployment.ingress.https-only_ to _false_ and _repo.deployment.ingress.ca_ to _self-signed_
-**NOTE:** In the absence of FQDN (i.e. for local deployment), TLS certificates can be disabled by setting the _repo.deployment.ingress.https-only_ to _false_ and _repo.deployment.ingress.ca_ to _self-signed_
- Set _repo.deployment.auth.provider-mode_ to _open_ and _repo.deployment.auth.github.redirect-uri_ to _`https://<VM-IP-address>/platform-ctrl/v1/authorize`_
- Set Prometheus external labels
-**NOTE:** This uniquely identifies Prometheus data sources in the long-term storage data buckets
@@ -203,7 +203,7 @@ This deployment configuration will require two VMs, see [Prerequisites](#prerequ
-`meepctl deploy core`
-**NOTE:** Wait for dep pods to be successfully deployed before deploying core
- Run `kubectl get pods -A` to see if all pods are up and running correctly
6. Install maps for the front-end:
6. Install maps for the frontend:
- Download the Monaco map tiles from [this link](https://data.maptiler.com/downloads/europe/france/monaco/)
- Copy the downloaded _.mbtiles_ file to the _~/.meep/omt/_ folder
- Restart the `open-map-tiles-xxxx-yy` container to load the maps
@@ -213,7 +213,7 @@ This deployment configuration will require two VMs, see [Prerequisites](#prerequ
## MEC Sandbox without Long-term Storage
This deployment configuration does not store metrics in a separate Storage VM. Instead, short-term metrics are stored in the same VM that is running the MEC Sandbox.
This deployment configuration does not store metrics in a separate Storage VM. Instead, short-term metrics are stored in the same VM that is running the MEC Sandbox. Hence only one VM is required for MEC Sandbox deployment.
1. Clone MEC Sandbox & AdvantEDGE repositories:
- Fetch required MEC Sandbox baseline:
@@ -232,7 +232,7 @@ This deployment configuration does not store metrics in a separate Storage VM. I
-`vi ~/mec-sandbox/config/.meepctl-repocfg.yaml`
- Set UID and GID in _repo.deployment.ingress.permissions_ (usually 1000 or 1001 on Ubuntu)
- Set _repo.deployment.ingress.host_ to VM FQDN (or IP address)
-**NOTE:** In the absence of FQDN, TLS certificates can be disabled by setting the _repo.deployment.ingress.https-only_ to _false_ and _repo.deployment.ingress.ca_ to _self-signed_
-**NOTE:** In the absence of FQDN (i.e. for local deployment), TLS certificates can be disabled by setting the _repo.deployment.ingress.https-only_ to _false_ and _repo.deployment.ingress.ca_ to _self-signed_
- Set _repo.deployment.auth.provider-mode_ to _open_ and _repo.deployment.auth.github.redirect-uri_ to _https://<VMIPaddress>/platform-ctrl/v1/authorize_
- Set the following values in `~/mec-sandbox/config/.meepctl-repocfg.yaml`:
@@ -300,7 +300,7 @@ This deployment configuration does not store metrics in a separate Storage VM. I
## User Provisioning
Users can be provisioned as admins for priviliged rights to configure and create network scenarios (see [Network Scenarios](./network-scenarios.md)) and have access to the monitoring dashboard. A step-by-step procedure to provision admin users is given below:
Users can be provisioned as admins for privileged rights to configure and create network scenarios (see [Network Scenarios](./network-scenarios.md)) and have access to the monitoring dashboard. A step-by-step procedure to provision admin users is given below:
1. Sign into the MEC Sandbox UI
1. On the _MEC Sandbox_ VM, note down or save the namespace in which new pods are being created by running `kubectl get pods -A`
@@ -330,7 +330,7 @@ Users can be provisioned as admins for priviliged rights to configure and create
Once the Sandbox is deployed, developers can learn how different services are running inside the kubernetes cluster. For each logged in user, a new sandbox instance (essentially a k8s namespace) is created, containing some base platform services as well as MEC Services that are enabled for the selected network scenario. Creation of namespaces and their pods for different users that log into the Sandbox can be monitored using [k9s](https://k9scli.io/).
Playing around with a 'live' deployment of MEC Sanbox offers great insight into the [Software Architecture](../Software-Architecture/README.md) of AdvantEDGE and its different components & subsystems. How different micro-services are communicating with each other in the backend can be investigated by interacting with the Sandbox frontend and invoking HTTP requests toward MEC Service APIs using the Swagger UI. See the [wiki page](https://mecwiki.etsi.org/index.php?title=MEC_Sandbox_Help) for more details on how to interact with the Sandbox.
Playing around with a 'live' deployment of MEC Sandbox offers great insight into the [Software Architecture](../Software-Architecture/README.md) of AdvantEDGE and its different components & subsystems. How different micro-services are communicating with each other in the backend can be investigated by interacting with the Sandbox frontend and invoking HTTP requests toward MEC Service APIs using the Swagger UI. See the [wiki page](https://mecwiki.etsi.org/index.php?title=MEC_Sandbox_Help) for more details on how to interact with the Sandbox.
Container logs from pods running the micro-services can be a great source of examining the messages and HTTP calls that are being exchanged between different services. To see the logs of a particular pod or a microservice, use the following command:
