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