Archived

Elektron is a lightweight, power-aware, pluggable Mesos framework that behaves as a playground to experiment with different scheduling policies to schedule ad-hoc jobs in docker containers.

This repository has been archived on 2024-04-10. You can view files and clone it, but you cannot make any changes to it's state, such as pushing and creating new issues, pull requests or comments.

Find a file

Pradyumna Kaushik 657dc8df93 Track resource usage across the cluster. Created utility in utilities/ to track the total and the unused resources for each host in the cluster. Added utility to def/taskUtils.go to retrieve the resource requirement for a given taskID. Decoupled the code, to launch a list of tasks on a set of offerIDs, to schedulers/helpers.go and updated all the scheduling policies to call this function instead of directly calling mesos.SchedulerDriver#LaunchTasks. The resource availability of the cluster is updated at 2 stages -- 1. When the tasks are about to be launched (in schedulers/helpers.go#LaunchTasks), the scheduling policy switching logic will be able to adhere to the update in the resource availability due to the JUST launched tasks and 2. when a terminal status update is received for a task (in schedulers/base.go#statusUpdate).		2018-09-23 17:44:36 -04:00
constants	Fixed the comments to be capitalized at the start and also terminate with a period.	2017-09-28 15:36:47 -04:00
def	Track resource usage across the cluster. Created utility in utilities/ to track the total and the unused resources for each host in the cluster. Added utility to def/taskUtils.go to retrieve the resource requirement for a given taskID. Decoupled the code, to launch a list of tasks on a set of offerIDs, to schedulers/helpers.go and updated all the scheduling policies to call this function instead of directly calling mesos.SchedulerDriver#LaunchTasks. The resource availability of the cluster is updated at 2 stages -- 1. When the tasks are about to be launched (in schedulers/helpers.go#LaunchTasks), the scheduling policy switching logic will be able to adhere to the update in the resource availability due to the JUST launched tasks and 2. when a terminal status update is received for a task (in schedulers/base.go#statusUpdate).	2018-09-23 17:44:36 -04:00
docs	moved documentation of scheduling policies and power-capping strategies into a documentation folder called docs/	2017-09-28 15:53:36 -04:00
environment	Now retrieving path to rapl throttle script by reading value of an environment variable. Also, stored the RAPL_PKG_Throttle.py script in a directory called scripts/. The location of this needs to be stored in an environment variable named RAPL_PKG_THROTTLE_LOCATION.	2017-09-28 15:01:06 -04:00
logging	Merged in experimentation/schedPolicySwitcher (pull request #1 )	2018-09-23 17:19:28 -04:00
pcp	Merged in experimentation/schedPolicySwitcher (pull request #1 )	2018-09-23 17:19:28 -04:00
power-capping	Merged in experimentation/schedPolicySwitcher (pull request #1 )	2018-09-23 17:19:28 -04:00
rapl	Now retrieving path to rapl throttle script by reading value of an environment variable. Also, stored the RAPL_PKG_Throttle.py script in a directory called scripts/. The location of this needs to be stored in an environment variable named RAPL_PKG_THROTTLE_LOCATION.	2017-09-28 15:01:06 -04:00
schedulers	Track resource usage across the cluster. Created utility in utilities/ to track the total and the unused resources for each host in the cluster. Added utility to def/taskUtils.go to retrieve the resource requirement for a given taskID. Decoupled the code, to launch a list of tasks on a set of offerIDs, to schedulers/helpers.go and updated all the scheduling policies to call this function instead of directly calling mesos.SchedulerDriver#LaunchTasks. The resource availability of the cluster is updated at 2 stages -- 1. When the tasks are about to be launched (in schedulers/helpers.go#LaunchTasks), the scheduling policy switching logic will be able to adhere to the update in the resource availability due to the JUST launched tasks and 2. when a terminal status update is received for a task (in schedulers/base.go#statusUpdate).	2018-09-23 17:44:36 -04:00
scripts	Now retrieving path to rapl throttle script by reading value of an environment variable. Also, stored the RAPL_PKG_Throttle.py script in a directory called scripts/. The location of this needs to be stored in an environment variable named RAPL_PKG_THROTTLE_LOCATION.	2017-09-28 15:01:06 -04:00
utilities	Track resource usage across the cluster. Created utility in utilities/ to track the total and the unused resources for each host in the cluster. Added utility to def/taskUtils.go to retrieve the resource requirement for a given taskID. Decoupled the code, to launch a list of tasks on a set of offerIDs, to schedulers/helpers.go and updated all the scheduling policies to call this function instead of directly calling mesos.SchedulerDriver#LaunchTasks. The resource availability of the cluster is updated at 2 stages -- 1. When the tasks are about to be launched (in schedulers/helpers.go#LaunchTasks), the scheduling policy switching logic will be able to adhere to the update in the resource availability due to the JUST launched tasks and 2. when a terminal status update is received for a task (in schedulers/base.go#statusUpdate).	2018-09-23 17:44:36 -04:00
.gitignore	removed .gitignore from the .gitignore file so as to include the gitignore file and start tracking.	2017-09-28 15:14:34 -04:00
config	updated pcp config file to not include stratos information	2017-09-26 01:40:17 -04:00
README.md	Linked to corresponding documentation	2017-09-28 15:56:16 -04:00
scheduler.go	Fix: mesos-go imports	2018-09-23 17:31:03 -04:00
workload_sample.json	updated example workload definition	2017-09-26 01:37:28 -04:00

README.md

Elektron: A Pluggable Mesos framework with power-aware capabilities

Elektron is a Mesos framework that behaves as a playground for developers to experiment with different scheduling policies to launch ad-hoc jobs. Elektron is designed as a lightweight, configurable framework, which can be used in conjunction with built-in power-capping policies to reduce the peak power and/or energy usage of co-scheduled tasks.

#Features