Cloud Computing Project Submission

Group Number 2

Members:

• Emin Arslan 1581975, fd0003933
• Yash Sharma 1573145, fd0003398
• Sagarkumar Dipakbhai Rokad 1566440, fd0003372
• Abhimanyu Rajesh Kanase 1569090, fd0003385

First Task

First we understood the architecture of the faafo application and commands. Then we changed the repository link in the install script for faafo to point to Emin's custom git repository. This was necessary because the demo deployment scripts pull from the remote repository when installing faafo on an instance and local changes are ignored.

After that, we added a few custom commands to the faafo command line tool. First we added a delete-all command, which deletes all fractals. Second, we added a delete-selected command, which takes a list of fractal UUIDs and deletes all of them. By adding these custom commands we achived a greater understanding of the faafo command line tool so that we can add more commands as needed in the future. We also added help messages for the new commands to provide a better user experience.

List of changed files for task 1:

• faafo/contrib/install.sh (changed repository link)
• demo2-instance-with-init-script.py (changed repository link)
• demo3-microservice.py (changed repository link)
• demo4-1-scale-out.py (changed repository link)
• demo4-2-scale-out-add-worker.py (changed repository link)
• faafo/bin/faafo (added commands)

Second Task

The faafo application as given stores all image data, including the image file itself in an SQL database. For the second task we changed the faafo API and worker programs (faafo/faafo/api/service.py and faafo/faafo/worker/service.py) to store the image file in OpenStack object storage. Other data about the image will still be stored in the database.

We changed the API server such that it will no longer store the image as a blob in the database. Instead, only a URL to the object containing the image data is stored, and the API retreives this data when the image is requested.

Upon first running the API, a new container with the name "fractals" will be created under our account. This container will hold all generated fractal image files.

OpenStack authentication is currently performed by a pre-generated application credential. In the first attempts we used password authentication directly. In a real deployment, it would be best to instead have the deployment script automatically generate a new set of application credentials for the API and workers to use.

OpenStack authentication using libcloud was a difficult roadblock. For a long while we were stuck on this issue, as the example given in the documentation did not work for us. We were eventually able to fix this by forcing v3 authentication directly and using the base URL instead of the one given by OpenStack. Here is the code example that worked for us:

from libcloud.storage.types import Provider
from libcloud.storage.providers import get_driver
import libcloud.security
libcloud.security.VERIFY_SSL_CERT = False

cls = get_driver(Provider.OPENSTACK_SWIFT)
# Use these parameters for v3 authentication
driver = cls(
    'CloudComp2', # username
    'demo', # password
    ex_force_auth_url='https://10.32.4.29:5000/', # NOT https://10.32.4.29:5000/v3
    ex_force_auth_version='3.x_password', # '3.x_appcred' for application credentials
    ex_tenant_name='CloudComp2',
    ex_domain_name='default'
)

print(driver.list_containers())

This code sample uses username and password directly for authentication. Our submitted faafo application instead uses application credentials to authenticate. In this case we had to change ex_force_auth_version to '3.x_appcred'.

We tried deploying using the demo2, demo3, demo4-1 and demo4-2 deployment scripts. All of these deployments were successful and made use of OpenStack object storage correctly, showing that the application in its current state is scalable.

List of changed files for task 2:

• faafo/faafo/api/service.py
• faafo/faafo/worker/service.py

A more detailed breakdown of what exact changes were made to which file can be found in our git repository history.