Using AppFlow from The GUI
AppFlow manages Services and Service Templates. A Service is a multi-tiered application composed of interconnected Virtual Machines with deployment dependencies between them.
The following diagram represents a multi-tier application. Each node represents a Role, and its cardinality (the number of VMs that will be deployed). The arrows indicate the deployment dependencies: each Role's VMs are deployed only when all its parent's VMs are running.
Services can be completely managed using the Sunstone web interface. AppFlow can be integrated with an existing Sunstone installation, read more in the configuration guide.
AppFlow allows OpenNebula administrators and users to register Service Templates in OpenNebula, to be instantiated later as Services. These Templates can be instantiated several times, and also shared with other users.
Users can manage the Service Templates using the Sunstone web interface. For each user, the actual list of Service Templates available is determined by the ownership and permissions of the Templates.
The previous example Service can be created using the Sunstone tab creation wizard:
The Template will appear in the AppFlow/Templates tab
A Service Template can be instantiated as a Service. Each newly created Service will be deployed by AppFlow following its deployment strategy.
Each Service Role creates Virtual Machines in OpenNebula from VM Templates, that must be created beforehand.
New Services are created from Service Templates, using the Instantiate
button:
The new Service can be seen in the Services tab. All Services are created in the PENDING
state.
The Service will eventually change to DEPLOYING
. You can see information for each Role and individual Virtual Machine using the bottom panel:
The deployment
attribute defines the deployment strategy that the Life Cycle Manager (part of the appflow-server) will use. These two values can be used:
RUNNING
.
Regardless of the strategy used, the Service will be RUNNING
when all of the Roles are also RUNNING
. Likewise, a Role will enter this state only when all the VMs are running
.
This table describes the Service states:
Service State | Meaning |
---|---|
PENDING | The Service starts in this state, and will stay in it until the LCM decides to deploy it |
DEPLOYING | Some Roles are being deployed |
RUNNING | All Roles are deployed successfully |
UNDEPLOYING | Some Roles are being undeployed |
FAILED | An error occurred while deploying or undeploying the Service |
UNKNOWN | After a successful deployment, an error was detected (e.g. a VM crashed) |
DONE | The Service will stay in this state after a successful undeployment. It can be deleted |
Each Role has an individual state, described in the following table:
Role State | Meaning |
---|---|
PENDING | The Role is waiting to be deployed |
DEPLOYING | The VMs are being created, and will be monitored until all of them are running |
RUNNING | All the VMs are running |
UNDEPLOYING | The VMs are being shutdown. The role will stay in this state until all VMs are done |
FAILED | An error occurred while deploying or undeploying the VMs |
UNKNOWN | After a successful deployment, an error was detected (e.g. a VM crashed) |
DONE | All the VMs are done |
Besides the current state, Sunstone will also show the different state changes:
Services are deployed automatically by the Life Cycle Manager. To undeploy a running Service, users have the buttons Shutdown
and Delete
.
The Shutdown
action will perform a graceful shutdown of all the running VMs, and will delete any VM in a failed state (see onevm shutdown and delete). If the straight
deployment strategy is used, the Roles will be shutdown in the reverse order of the deployment.
After a successful shutdown, the Service will remain in the DONE
state. If any of the VM shutdown operations cannot be performed, the Service state will show FAILED
, to indicate that manual intervention is required to complete the cleanup. In any case, the Service can be completely removed using the Delete
action.
If a Service and its VMs must be immediately undeployed, the button Delete
can be used from any Service state. This will execute a delete operation for each VM and delete the Service. Please be aware that this is not recommended, because VMs using persistent Images can leave them in an inconsistent state.
Both Services and Template resources are completely integrated with the OpenNebula user and group management. This means that each resource has an owner and group, and permissions. The VMs created by a Service are owned by the Service owner, so he can list and manage them.
To change the owner and group of the Service, we can use the Change owner/group
buttons:
Note that the Service's VM ownership is also changed:
All Services and Templates have associated permissions for the owner, the users in its group, and others. For each one of these groups, there are three rights that can be set: USE, MANAGE and ADMIN. These permissions are very similar to those of UNIX file system, and can be modified with the button Update properties
.
For example, to allow all users in the apptools
group to USE (list, show) and MANAGE (shutdown, delete) the Service 2:
Another common scenario is having Service Templates created by oneadmin that can be instantiated by any user. To implement this scenario, give USE permissions to Other:
Please refer to the OpenNebula documentation for more information about users & groups, and resource permissions.