Added README.md
This commit is contained in:
BIN
.demo2-instance-with-init-script.py.swp
Normal file
BIN
.demo2-instance-with-init-script.py.swp
Normal file
Binary file not shown.
98
README.md
Normal file
98
README.md
Normal file
@ -0,0 +1,98 @@
|
|||||||
|
# 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](https://git.emin.software/haxala1r/cloud-computing-msc-ai-examples). 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](https://git.emin.software/haxala1r/cloud-computing-msc-ai-examples).
|
Reference in New Issue
Block a user