Deploy instructions¶
Step 1 : Clone Repo¶
Clone or pull this repo and cd
into the repo’s directory.
Step 2 : Update Node list¶
List of nodes for the experiment is kept in file nodes.txt
(the user needs to fill the file with the appropriate kubernetes nodenames of their compute nodes).
You can simply change just the hostnames in the given sample file. The first line should be
home nodename
Everything else can be the same.
home | nodename |
---|---|
node1 | nodename |
node2 | nodename |
node3 | nodename |
Step 3 : Setup Home Node¶
You need to setup the configurations for the circe home, wave home, and the central profiler.
For convienice we statically choose a node that will run all dockers.
To set that, you have to change the following line in your jupiter_config.py
file.
1 | HOME_NODE = 'ubuntu-2gb-ams2-04'
|
This should point to a resource heavy node where you want to run them. We kept it like this for convinience. However in future, this will be made dynamic as well. Next, we also need to point the child of CIRCE master. The CIRCE master is used to dispatch input files to tha DAG. Thus it should point to the ingress tasks of the DAG. Change the following line in the config file to achieve that.
1 | HOME_CHILD = 'sample_ingress_task1'
|
For example, in the linked example of Network Monitoring, it is a single task called localpro
.
But if there are multiple ingreass tasks, you have to put all of them by separating them by a :
.
Step 4 : Setup APP Folder¶
You need to make sure that you have a APP_folder
with all the task specific files
inside the task_specific_files
folder. The APP_folder
needs to have a configuration.txt
,``app_config.ini`` and name_convert.txt
.
The APP_folder
MUST also contain all executable files of the task graph under the scripts
sub-folder.
You need to follow this exact folder structure to develop an APP for the Jupiter Orchestrator.
Note
Detailed instructions for developing APPs for Jupiter will be posted later.
APP_folder
|
| configuration.txt
| app_config.ini
| name_convert.txt
|
└───scripts
|
└───sample_input
Step 5 : Setup the Dockers¶
Version 2.0 and 3.0¶
Starting from version 2.0, to simplify the process we have provided with the following scripts:
1 2 3 4 | circe/circe_docker_files_generator.py --- prepare Docker files for CIRCE
profilers/execution_profiler/exec_docker_files_generator.py --- for execution profiler
profilers/network_resource_profiler/profiler_docker_files_generator.py --- for DRUPE
task_mapper/heft/heft_docker_files_generator.py --- for HEFT
|
These scripts will read the configuration information from jupiter_config.ini
and jupiter_config.py
to help generate corresponding Docker files for all the components.
Version 4.0¶
The automatic scripts paths are updated:
1 2 3 4 5 6 7 8 9 | circe/original/circe_docker_files_generator.py --- prepare Docker files for CIRCE (nonpricing)
circe/pricing_event/circe_docker_files_generator.py --- prepare Docker files for CIRCE (event driven pricing)
circe/pricing_push/circe_docker_files_generator.py --- prepare Docker files for CIRCE (pushing pricing)
profilers/execution_profiler_mulhome/exec_docker_files_generator.py --- for execution profiler
profilers/network_resource_profiler/profiler_docker_files_generator.py --- for network profiler
task_mapper/heft_mulhome/original/heft_docker_files_generator.py --- for HEFT (original)
task_mapper/heft_mulhome/modified/heft_docker_files_generator.py --- for HEFT (modified)
task_mapper/wave_mulhome/greedy_wave/wave_docker_files_generator.py --- for WAVE (greedy)
task_mapper/wave_mulhome/random_wave/wave_docker_files_generator.py --- for WAVE (random)
|
Step 6 : Choose the task mapper¶
You must choose the Task Mapper from config.ini
. Currently, there are 4 options from the scheduling algorithm list: centralized (original HEFT, modified HEFT), distributed(random WAVE, greedy WAVE).
1 2 3 4 5 6 7 8 9 | [CONFIG]
STATIC_MAPPING = 0
SCHEDULER = 1
[SCHEDULER_LIST]
HEFT = 0
WAVE_RANDOM = 1
WAVE_GREEDY = 2
HEFT_MODIFIED = 3
|
Note
When HEFT tries to optimize the Makespan by reducing communication overhead and putting many tasks on the same computing node, it ends up overloading them. While the Jupiter system can recover from failures, multiple failures of the overloaded computing nodes actually ends up adding more delay in the execution of the tasks as well as the communication between tasks due to temporary disruptions of the data flow. The modified HEFT is restricted to allocate no more than MAX_TASK_ALLOWED
containers per computing node where the number MAX_TASK_ALLOWED
is dependent upon the processing power of the node. You can find MAX_TASK_ALLOWED
variable from heft_dup.py
.
Step 7 : Optional - Choose the CIRCE dispatcher (only starting from Version 4)¶
Starting from Jupiter Version 4, you must choose the CIRCE dispatcher from config.ini
. Currently, there are 3 options from the dispatcher list: nonpricing, pricing (event driven scheme, pushing scheme)
Step 8 : Optional - Modify the File Transfer Method or Network & Resource Monitor Tool¶
Select File Transfer method¶
Jupiter by default use SCP
as the file transfer method. If you want to use any other file transfer tool instead (like XCP
, etc…), you can perform the following 2 steps:
Firstly, refer the Integration Interface and write your corresponding File Transfer module.
Secondly, update config.ini
to make Jupiter use your corresponding File Transfer method.
1 2 3 4 5 | [CONFIG]
TRANSFER = 0
[TRANSFER_LIST]
SCP = 0
|
Select Network & Resource Monitor Tool¶
Jupiter by default use DRUPE
as the Network & Resource Monitor Tool. If you want to use any other Network & Resource Monitor Tool, you can perform the following 2 steps:
Firstly, refer the Integration Interface and write your corresponding Network & Resource Monitor module.
Secondly, update config.ini
to make Jupiter use your corresponding Network & Resource Monitor module.
1 2 3 4 5 | [CONFIG]
PROFILER = 0
[PROFILERS_LIST]
DRUPE = 0
|
Step 9 : Push the Dockers¶
Now, you need to build your Docker images.
To build Docker images and push them to the Docker Hub repo, first login
to Docker Hub using your own credentials by running docker login
. Starting from Jupiter Version 2, we have provided with the following building scripts:
scripts/build_push_jupiter.py --- push all Jupiter related dockers
scripts/build_push_circe.py --- Push CIRCE dockers only
scripts/build push_profiler.py --- Push DRUPE dockers only
scripts/build_push_wave.py --- Push WAVE dockers only
scripts/build_push_heft.py --- Push HEFT dockers only
scripts/build_push_exec.py --- Push execution profiler's dockers only
The build path scripts are modified in Jupiter Version 4:
mulhome_scripts/build_push_jupiter.py --- push all Jupiter related dockers and nonpricing circe dispatcher
mulhome_scripts/build_push_pricing_jupiter.py --- push all Jupiter related dockers and pricing circe dispatcher
mulhome_scripts/build_push_circe.py --- Push nonpricing CIRCE dockers only
mulhome_scripts/build_push_pricing_circe.py --- Push pricing CIRCE dockers only
mulhome_scripts/build push_profiler.py --- Push DRUPE dockers only
mulhome_scripts/build_push_wave.py --- Push WAVE dockers only
mulhome_scripts/build_push_heft.py --- Push HEFT dockers only
mulhome_scripts/build_push_exec.py --- Push execution profiler's dockers only
Warning
However, before running any of these scripts you should update the jupiter_config
file with your own docker names as well as dockerhub username. DO NOT run the script without crosschecking the config file.
Step 10 : Optional - Setup the Proxy (only required for Version 2 & 3)¶
Now, you have to create a kubernetes proxy. You can do that by running the follwing command on a terminal.
1 | kubectl proxy -p 8080
|
Step 11 : Create the Namespaces¶
You need to create difference namespaces in your Kubernetes cluster that will be dedicated to the DRUPE, execution profiler, Task Mapper, and CIRCE deployments, respectively. You can create these namespaces commands similar to the following:
1 2 3 4 | kubectl create namespace johndoe-profiler
kubectl create namespace johndoe-exec
kubectl create namespace johndoe-mapper
kubectl create namespace johndoe-circe
|
Warning
You also need to change the respective lines in the jupiter_config.py
file.
1 2 3 4 | DEPLOYMENT_NAMESPACE = 'johndoe-circe'
PROFILER_NAMESPACE = 'johndoe-profiler'
MAPPER_NAMESPACE = 'johndoe-mapper'
EXEC_NAMESPACE = 'johndoe-exec'
|
Step 12 : Run the Jupiter Orchestrator¶
Next, you can simply run:
1 2 | cd mulhome_scripts/
python3 auto_deploy_system.py
|
Step 13 : Optional - Alternate scheduler¶
If you do not want to use our task mappers (HEFT
or WAVE
) for the scheduler and design your own, you can do that by simply using the static_assignment.py
. You must do that by setting STATIC_MAPPING
to 1
from jupiter_config.ini
. You have to pipe your scheduling output to the static_assignment.py
while conforming to the sample dag and sample schedule structure. Then you can run:
1 2 | cd mulhome_scripts/
python3 auto_deploy_system.py
|
Step 14 : Interact With the DAG¶
Now you can interact with the pos using the kubernetes dashboard.
To access it just pen up a browser on your local machine and go to
http://127.0.0.1:8080/ui
. You should see the k8s dashboard.
Hit Ctrl+c
on the terminal running the server to turn off the proxy.