When testing and debugging APS packages on a demo Odin Service Automation system, you can enable the APS development mode that affects the system in the following way:
You can enable this mode on your demo system by these steps:
Integration of an application with Odin Service Automation is going through the application APS package, which usually contains the following parts as presented below:
Depending on application complexity, the package structure can be more complicated and it can contain much more files.
Initial APS package processing in Odin Service Automation contains the following steps:
On completion of the above steps, the provider will be able to proceed with the following configuration steps:
If you have administration permissions in the Odin Service Automation system, you can import a package following these steps in the provider control panel.
Each APS application must expose at least one APS application endpoint, or shorter endpoint, that will be able to receive REST requests from the APS controller. Endpoint deployment requires the following high level steps:
APS endpoint for an application can be set up in one of two ways.
The application endpoint setting can be automated by means of the endpoint.sh utility. If you are working on a sandbox, the utility already exists on the host. When you start it, the utility configures the platform (Apache and SSL), if needed, and then creates the required APS endpoint. The method consists of two steps.
Copy the APS package to the endpoint host. For example, if your package is Sample_VPS_Cloud-1.0-1.app.zip and base domain of your sandbox is a.isv1.apsdemo.odin.apsdemo.org:
scp Sample_VPS_Cloud-1.0-1.app.zip email@example.com:
Log in to the endpoint host and use the endpoint.sh utility on your endpoint host to setup an APS application endpoint in a specified folder. For example, if you have package Sample_VPS_Cloud-1.0-1.app.zip and need to install an endpoint in the folder /var/www/html/vpscloud, enter the following command:
endpoint.sh vpscloud Sample_VPS_Cloud-1.0-1.app.zip
The utility will print out the URL for the endpoint, e.g.: https://endpoint.a.isv1.apsdemo.org/vpscloud.
If you need to add some configuration steps after the outlined ealier high level step are over, add the shell script named pre-configure.sh. It must be placed in the application endpoint folder. If such script is present, the endpoint.sh script will call it, once the basic configuration is done. Notice that endpoint.sh exports the ENDPOINT_LOCATION variable - path to the application endpoint folder, where the application provisioning scripts are located. This variable can be used in pre-configure.sh. Example of pre-configure.sh can be found in VPS Backup demo package.
When setting endpoint manulally, we need to separate Platform Setup (used once per platform) from APS Endpoint Setup (used per each APS application endpoint installation). This method is not recommended as it is time consuming and prone to mistakes. We provide the details here to help you create one of automated methods.
The host, on which APS endpoints will be set up for different applications, needs to be configured. To do it on a CentOS Linux, the following steps are needed:
Enable HTTPS and client SSL certificate verification:
yum install mod_ssl
In /etc/httpd/conf.d/ssl.conf, uncomment the SSLVerifyClient option and set it to optional_no_ca:
In /etc/httpd/conf.d/ssl.conf, configure the <Files> section as follows:
<Files ~ "\.(cgi|shtml|phtml|php3?)$"> SSLOptions +StdEnvVars +ExportCertData </Files>
service httpd restart
If you are going to use the APS PHP runtime framework, make sure the standard PHP package and APS PHP runtime library are installed on the host. For example, verify it as follows:
rpm -qa | grep php
If one or both of them are not installed, you can use the commands below appropriately:
yum install php yum install http://download.apsstandard.org/php.runtime/aps-php-runtime-2.0-353.noarch.rpm
Pay attention, the runtime version might increase by the time you will do these operations. Please use the URL for the latest version.
Set the AllowOverride All option for the folder that will be the parent of application endpoints. It is usually var/www/html in Apache. For example, in the /etc/httpd/conf/httpd.conf file, find the <Directory “var/www/html”> section and edit the following line:
Restart the Apache service:
service httpd restart
For setting an APS application endpoint manually, you need to follow these steps.
Create the application endpoint folder. For instance, the /var/www/html/vpscloud folder will be used in following steps.
Copy all provisioning scripts, i.e. PHP and other files from the scripts folder of the package to the application endpoint folder, i.e. to /var/www/html/vpscloud/ in our example.
Make sure the user apache is the owner of the endpoint folder and all its contents:
chown -R apache:apache /var/www/html/vpscloud
Set redirect from each URL that exposes an application service to the PHP file that implements the service. For example, if in metadata you declared four different services named clouds, offers, contexts, and vpses, you will probably have cloudes.php, offers.php, contexts.php, and vpses.php files. The redirect is configured by creating the .htaccess file just inside the vpscloud folder with the following content:
Options +FollowSymLinks +ExecCGI <IfModule mod_rewrite.c> RewriteEngine On RewriteBase /vpscloud RewriteRule ^clouds(|/.*)$ clouds.php?q=$1 [L,QSA] RewriteRule ^contexts(|/.*)$ contexts.php?q=$1 [L,QSA] RewriteRule ^offers(|/.*)$ offers.php?q=$1 [L,QSA] RewriteRule ^vpses(|/.*)$ vpses.php?q=$1 [L,QSA] </IfModule>
Restart the Apache service:
service httpd restart
Installation of the APS application instance in Odin Service Automation is needed to establish the secured connection between the APS controller and the application. During this process, the APS controller must generate an application certificate for the application and send it to the application instance through the application endpoint. The provider should do this operation in the Operations Automation provider control panel following these directions:
Global resources are shared for all customers. For example, they can be used for offering a number of possible configurations from which customers can choose whichever is better for them when purchasing a resource as demonstrated at Custom Resource Relations. Suppose, our demo package allows the provider to create a number of VPS offers (Platinum, Premium, and Starter offers) in order customers can select them when purchasing VPSes. For example, a customer can purchase 15 VPSes, two of them will be based on the Platinum offer, three on Premium, and ten on Starter.
To create an offer, the provider should go through the following steps in the Operations Automation provider control panel:
Open the application instance screen and switch to the Samples tab.
Such a tab will appear if the custom UI in the package contains the Samples item in the declared navigation tree and a UI view element presenting the Samples tab.
Create the needed number of offers using custom UI.
Odin Service Automation contains APS resource classes used for presenting different APS resources as explained in the table:
|APS Component||Odin Service Automation Resource Class||Example in Diagram||Description|
|Application||Application Service Reference||cloud||APS application instance related to all other resources.|
|Global Resource||Application Service Reference||offer||APS resources with global settings. They must relate to Application.|
|Resource Type||Application Service||context, vps||APS resources owned by an account or end-user.|
|Resource Counter||Application Counter||CPU cores, Memory||Counter of an application resource consumption.|
The table helps providers to correctly select the Odin Service Automation resource class when creating a list of needed Odin Service Automation resource types. Application Counter class actually is presented with its modifications that should be selected depending on the unit of measure used by the resource counter:
To create a resource type in Operations Automation, providers goes through the following general steps:
The provider needs to repeat the outlined process until all needed resources are created.
The resource providing management context for customers must have the Autoprovisioning attribute marked.
All resources created in the previous step the provider usually includes into the service template that will be used for provisioning the application services to customers. Service providers follow these steps in the Operations Automation control panel to create the needed service template (ST).
Navigate to Products > Service Templates and click Add New Service Template.
Enter the ST name, e.g. Cloud VPS Services, mark the Autoprovisioning box, make sure Custom is selected in the drop-down Type list, and click Next.
Select all APS related resource that were created at the previous step. Probably, the application needs some other resources, e.g. DNS hosting. Add them as needed, and then click Next.
If you missed any resources at this step, you can easily add them later, after the ST is created.
Set resource limits keeping in mind the following key points:
Save the ST, and then activate it by clicking the Activate button.
Our demo application is presented with the following Odin Service Automation service template:
In accordance with this ST, the total number of virtual servers is unlimited. However, a subscriber cannot create more than 15 servers, as the total limit on the number of VPS configurations (offers) that the customer can select is 2+3+10=15. Still, please keep in mind that the limits can be overridden in a service plan based on this ST.