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.
What Is a Service?
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.
Managing Service Templates
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.
Create and List Existing Service Templates
The previous example Service can be created using the Sunstone tab creation wizard:
The Template will appear in the AppFlow/Templates tab
Managing Services
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.
Create and List Existing Services
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:
Life-cycle
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:
- none: All roles are deployed at the same time.
- straight: Each Role is deployed when all its parent Roles are
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:
Life-Cycle Operations
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.
Managing Permissions
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.