Commit 4614ec09 authored by Balazs's avatar Balazs

Merge branch 'master' of gitlab.switch.ch:Verbaryerba/disco

Conflicts:
	README.md
parents 525f3628 88fb6b84
<<<<<<< HEAD
# Description of hurtle
=======
# Short description of Repository
Many things might seem trivial/self-evident; others might not be clear enough. Please contact me if you are having problems or need some clarification in some point.
### What needs to be changed (partly optional):
- sm/so/service_orchestrator.py -> STG_FILE
- bundle/wsgi/so.py -> os_image, ssh_key
- bundle/data/cluster.yaml -> "default" at master_flavor, slave_flavor; network under hadoop_router; floating_network under hadoop_ip
- etc/sm.cfg -> manifest, design_uri
## description of mentioned changes
### service_orchestrator.py
Necessary if you run the Service Manager.
- STG_FILE has to point to the bundle/data/service_manifest.json file.
### so.py
This is the actual Service Orchestrator with the necessarily implemented methods for design, deploy, update, delete, etc. Amongst others, it sets some configuration specifics in the Heat templates as well as creating the actual template for the required cluster size.
- os_image has to point to an existing (Debian based) image on the hosting OpenStack.
- ssh_key has to be an existing SSH key within OpenStack which will be inserted into the generated Master instance. This will be the access point of the created cluster.
### cluster.yaml
cluster.yaml is the Heat Template for the basic cluster. In this file is the setup for the components which will be used by all instances (i.e. network, router, master, ...)
- master_flavor, slave_flavor are the flavors of the generated instances. They determine the specific virtual ressources of the created virtual machines. They might have to be changed for a different OpenStack installation. (provided that the administrator has changed the default names)
- network, floating_network need the name of the public network of the local OpenStack installation. This can be looked up in the OpenStack Horizon dashboard under Network Topology for instance.
### sm.cfg
This is the configuration file for the Service Manager. Only needed if the Service Manager is to be run.
- manifest points to the bundle/data/service_manifest.json if the Service Manager is running.
- design_uri is the URI for the keystone endpoint of OpenStack.
Below is the pasted command introduction to Service Orchestrators from the Sample SO page mentioned in the Wiki.
# Testing SO without deploying it using CC
>>>>>>> 88fb6b843d203b7aa6013fc7c6b15004e8c0410e
At the moment, I have only managed to deploy a cluster on our local OpenStack installation even though I have admin access on Switch Engine's OpenStack tenant. For this reason, I only want to explain which are the main settings within the config files. One more thing: I explain everything for deployment on OpenShift 3 which itself includes the PaaS system Docker.
......@@ -33,4 +73,4 @@ The [general] section has some information about logging. You can log either loc
The section [cloud_controller] deals with the CC_API. Here, the login information of the OpenShift installation will have to be set. nb_api, user and pwd need to be filled with OpenShift's URL, its username and that user's password. If the connection cannot be established, wait_time and max_attempts will define how many retries shall be done with which waiting time between two retries.
## so.py
This is the file where the actual implementation of the SO is done. I'm not going to go into the details here. I just want to mention that this file will be included by the bundle/wsgi/application file. application is the very same file which will be executed on OpenShift as the SO instance. It will then delegate the requests (including the given attributes) to the so.py file. The given attributes can be accessed in the attributes dictionary in the individual methods.
\ No newline at end of file
This is the file where the actual implementation of the SO is done. I'm not going to go into the details here. I just want to mention that this file will be included by the bundle/wsgi/application file. application is the very same file which will be executed on OpenShift as the SO instance. It will then delegate the requests (including the given attributes) to the so.py file. The given attributes can be accessed in the attributes dictionary in the individual methods.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment