Tutorials/CloudSim/development

CloudSim development ==

CloudSim is a web app that runs in a virtual machine on the AWS (Amazon Web Services) cloud. This guide will show you how to run a local copy of CloudSim on your development machine. It also covers tools and tricks to get insights on its internals.

The code can be found here:

https://bitbucket.org/osrf/cloudsim

Prerequisites ==

Here are the packages that need to be installed in order to run and develop CloudSim

sudo apt-get install -y python python-paramiko openssh-client unzip zip mercurial apache2 redis-server python-pip python-redis python-dateutil expect cmake python-software-properties openvpn python-novaclient build-essential sudo pip install boto==2.8.0 sudo pip install softlayer

sudo pip install unittest-xml-reporting sudo apt-add-repository -y ppa:rye/ppa sudo apt-get update sudo apt-get install -y libapache2-mod-auth-openid sudo ln -sf /etc/apache2/mods-available/authopenid.load /etc/apache2/mods-enabled

System overview ==

CloudSim is a distributed system that runs on a server machine inside multiple processes (the web server and the CloudSim daemons). These processes interact with each other via the file system and the Redis key-value store. The CloudSim server controls the life cycle of multiple virtual machines on the Cloud. The user interacts with it via their web browser. Here is a description of the various processes, their roles and the source code.



Redis is a key-value store program that is used as an IPC mechanism between the daemons and the web app. http://redis.io/ It needs to be installed on the CloudSim server, and the Redis-server daemon must be running (it runs by default on Ubuntu once installed).
 * 1) Redis server

* Create simulation constellations * Stop constellations * Start a simulation * Stop a simulation * Monitor a simulation constellation (latency, setup status, X) Cloudsimd uses the common library code (in cloudsim/inside/cgi-bin/common), so PYTHONPATH must be set accordingly. It contains a launchers module. Each file in this module corresponds to a configuration that can be launched with CloudSim.
 * 1) cloudsimd
 * This is a python program that launches simulators and other machines in the cloud. It is installed as an upstart daemon (http://upstart.ubuntu.com/).
 * It listens for commands using redis publish/subscribe channels. The web app listen to these messages.
 * The source code is found in cloudsim/cloudsimd.
 * The entry point is cloudsimd.py.


 * 1) Web server
 * The apache web server runs python cgi scripts that implement the REST api and serve the web application to the users. It uses redis to communicate with Cloudsimd and cloudsim_monitord.
 * The web server also sends ssh commands to simulator machines and router machines to measure latency and impose bandwidth restrictions
 * The web server loads an apache2 module that performs OpenID authentication. The login.html page is the entry point to the application.
 * The source code is in cloudsim/inside/cg-bin directory. The common subdirectory contains the source code for the common library.


 * 1) Web browser (running the web app)
 * The source code to the web app is mostly contained in the 'cloudsim/js' directory. The `cloudsim/inside/cgi-bin/console.py` serves a minimal page that includes all the javascript files (and dependencies like jquery / jqueryui and flotcharts). The on_load page event subscribes to server events that are propagated to the widgets.

CloudSim uses the file system to store files and state information (mostly key files, scripts) for each machine. The information stored on disk may eventually migrate to the Redis key-store.
 * 1) Disk (file system)

Deployment (VRC) ==

This is an overview of the constellation deployment for the VRC taks: Each team will be provided with a constellation of 3 machines:
 * The simulator: this machine runs Gazebo and the ROS master. It should only communicate to the field computer via ROS.
 * The field computer: this machine runs the code for the team. The team has ssh access to it and it can reach the internet via the router.
 * The router computer: this is the VPN server and the access point to the constellation. It will limit the bandwidth between the team's lab and the field computer

This deployment uses the AWS (Amazon Web Service) VPC (Virtual Private Cloud) and Elastic Ips (Internet addresses)




 * 1) Simulator Computer

The simulator computer's startup script does the following:
 * Setup the /etc/apt/sources.list
 * Create a start_sim.bash script
 * Adds the ROS and OSRF packages repositories
 * Setup the keys for the ROS and OSRF Debian packages repository
 * apt-get update

route add 11.8.0.2 gw 10.0.0.50
 * add a route to the OCU via the Router


 * Nnstall the nvidia drivers
 * Setup X: create etc/X11/xorg.conf
 * Create an autologin user for gnome
 * Start lightdm
 * Install ntp, drcsim and cloudsim-client-tools


 * 1) Field Computer


 * Same setup as the simulator (for nor)


 * 1) Router Computer

dev tun ifconfig 11.8.0.1 11.8.0.2 secret static.key chmod 644 /etc/openvpn/static.key sysctl -w net.ipv4.ip_forward=1 iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT iptables -A FORWARD -o tun0 -i eth0 -j ACCEPT
 * Install openvpn
 * Create an OpenVPN server configuration script
 * Generate an openvpn key in /etc/openvpn/static.key (to be downloaded by CloudSim later)
 * Restart openvpn

All these computers are created in the context of an Amazon VPC
 * 1) Tying it all together
 * A security group is created for each machine
 * An elastic IP is acquired for teh Router (its done for each machine right now)
 * A VPC is created
 * An Internet Gateway is created
 * A routing table with a 0.0.0.0/0 route to the gateway
 * Keys are generated for each machine
 * The sourceDestCheck parameter is set to false on the Router
 * init.d level 2 scripts are created on the machines to set routes between them

Machines take about 20 min to provision and reboot

Hacking ==

CloudSim uses the www-data user to access the disk. It creates `/var/www-cloudsim-auth` and `/var/www` directories.

Getting the code. ===

Use Mercurial to get the code (i.e, from your bitbucket account). The address of the repository varies depending if you use a read only public access or if you have forked the repository in your bitbucket account. Please refer to Mercurial and bitbucket documentation.

hg clone https://xxx@bitbucket.org/cloudsim cd cloudsim

The first time you deploy, you will need to give your admin user to the application. Edit the content of the `cloudsim/distfile/users` to set your email address. You can also edit the `/var/www-cloudsim-auth/users` after deployment. You can change the address with yours. The format is a simple JSON dictionary. You can also add new addresses and roles, by adding "xxx@xxx.xxx": "role".

{"hugo@osrfoundation.org":"admin","caguero@osrfoundation.org":"admin"}

Versionning === CloudSim uses cmake to generate a VERSION file that contains the displayed version of CloudSim. To generate it, run cmake in the cloudsim/build directory mkdir build cd build cmake ..

AWS account info You must have valid AWS credentials for CloudSim. In the parent directory of cloudsim, create a `boto.ini` The file is kept outside of the CloudSim directory to prevent adding it to the Mercurial repository by mistake, since it could allow people to launch machines under your AWS account. Add the following content to `boto.ini`:

[Credentials] aws_access_key_id = XXXXXXXXXXXX aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXX

[Boto] ec2_region_name = us-east-1b ec2_region_endpoint = ec2.amazonaws.com

Deploy the application locally by running the deploy.sh script. This overrides your apache2 configuration so you may want to save your `/etc/apache2/apache2.conf` file before running it.

. deploy.sh

Login via your browser at `http://localhost`. The first time you login, you will need to set your AWS credentials in order to launch machines.

Tools ==

Cloudsim contains a few unit tests to help isolate problems. Tests are run automatically after new code is checked in. The `cloudsim/cloudsimd/cloudsimd-spy.py` is a scripts that prints redis messages to the console. It is useful for tracing and debugging purposes.

With the current code, the Simulator machine and the Field computers are not able to access the Internet. The current temporary workaround is to assign them an elastic IP.
 * 1) Problems with 1.4 version

We need all Internet traffic from the Field Computer to go through the Router (via the VPN), because this traffic must be limited (to 1 or 2 mbits/s) during the competition.

We are looking into this.


 * 1) Next ##

Next: Troubleshooting CloudSim