Working with the ECloud Stamp

Ruben de Juan

This document describes how you can use the Integration Testing Tool (ITT) to interact with the ECloud instance -ECloud Stamp- (real Cloud infrastructure for the C2NET project). This document is structured as follows:

  • In the first section it is presented the different ways you can use the ITT for deploying services and using them.
  • The second section details the different operations supported by ITT that allow the different working ways.

How to use the ITT

Currently, ITT supports two main working ways with ECloud:

  • ECloud External Access: this allows you to deploy a service and access it externally using http/https requests from the outside (f.e. web browser), and later on undeploy it.

  • ECloud Automated Testing: this way allows to deploy a service for testing it in an automated way providing also the service acting as tester. This way of working does not support external accesses to the service. In this case, the service is undeployed when the test finishes.

Basics

FTP Access

Interaction with ITT is done putting files to the FTP server provided by ATOS. Those files usually will be a json Manifest that specifies the operation to performed and in some cases a zip file containing a bundle. Once the manifest is processed by the ITT, a response will be created in the /log folder with a timestamp added to the manifest file name you have previously created.

The connection details for this FTP server are available in the C2NET portal.

Naming Convention for Services and Components

From now on, each component and service name MUST begin with 'eslap://c2netproject'.

If you do not follow this, the components and services won't be processed correctly.

ECloud External Access

This way of working enables you to:

  • register your service and deploy it into the ECloud Stamp
  • then interact with it from the outside (through a proxy) and accessing the logs
  • finally, undeploy it (optionally you can unregister it and their components)

The steps to be done are the following:

  1. Create a zip file with the components of the service, the service application manifest and the service deployment manifest.
  2. Prepare the Register Manifest for this service. In the field bundle of the Manifest you have to put the name of the zip file created in step 1.
  3. Copy to the FTP server (/integration-test/bundles folder) the zip file created in step 1.
  4. Now copy the Register Manifest created in step 2 in the FTP server (/integration-test/manifest folder).
  5. At this moment ITT processes the Register Manifest and performs needed operations until deploying the service. Note: the deployment is done if the zip file (of step 1) contains a service deployment manifest.
  6. Sometime later, check in the FTP server the log folder (/integration-test/logs) and look for a file with the same name as the Register Manifest (the one copied in step 4) with a timestamp. This file contains the result of the process (even unsuccessful).
  7. Check in this file for the url of the service that is the value of the field domain (e.g. my-domain.osdmz.iti.es). Example of admission can be found in Appendix AdmissionResponse example.
  8. Now configure the proxy of your web browser or the HTTP tool you usually use as commented here, then you will be able to access the url provided.
  9. Then have fun with your service...
  10. Once you have finished playing with your service, undeploy it. To do so create an Undeploy Service Manifest and copy it to the FTP server (/integration-test/manifest folder). The deploymentURN value to be provided has to be taken from the file generated in step 6 (response of the Admission service).
  11. After this step, optionally you can also unregister it creating an Unregister Service Manifest and copy if to the FTP server (/integration-test/manifest folder). In the field serviceURN you have to use the value provided in the field service of the file generated in step 6 (response of the Admission service)
  12. If you want to access the logs generated when playing with your service you have to copy to the FTP server (/integration-test/manifest folder) a Log Manifest. The deploymentURN value to be provided has to be taken from the file generated in step 6 (response of the Admission service).

Last remark, in the case you try to register again a service previously registered without changing the version number, ECloud will use the old version of the service (not the new one) and will warn you.

This is the most general way for deploying services and accessing them from the outside. There are other operations supported by ITT for registering and unregistering components and so on. Please take a look to the ITT Operations.

ECloud Automated Testing

This options enables you to execute a Test Bundle which is performed by the ITT autonomously. Instructions about how to create a Test Bundle are explained in detail in the Quick Start Guide as well as to verify the results.

In short this section will be extended.

ITT Operations

Currently, the ITT (Integration Testing Tool) supports the following operations in the ECloud Stamp:

  • Register Component/Service
  • Deploy Service
  • Undeploy service
  • Unregister Component
  • Unregister Service
  • Get Logs
  • Execute Test (old way of working)

You will find additional details about how to execute these actions in the following sections.

From now on, each component and service name MUST begin with 'eslap://c2netproject'.

If you do not follow this, you will not be able to access the logs

Register Component/Service

To register a component or a service into ECloud, a .zip file must be uploaded in the integration-test/bundles folder. Then, to trigger the registering, a new manifest shall be placed in /integration-test/manifest folder with the following format:

RequestRegister.json:

{
  "action": "register",
  "bundle": "JobexService.zip"
}

If the register was successfully executed, then a new .json is created in /integration-test/logs folder containing the response from ECloud admission.

If you include a deployment manifest into the .zip, then it will deploy the service as well.

Deploy Service

To deploy a service, both the service and the components must be registered into the ECloud. Create a new .zip file with a deployment manifest and then upload it into the integration-test/bundles folder. To trigger the action, create a new manifest in /home/c2net/integration-test/manifest as follows:

RequestDeploy.json:

{
  "action": "deploy",
  "bundle": "JobexServiceDeployment.zip"
}

If the deployment was successfully executed, then a new .json is created in /integration-test/logs folder containing the response from ECloud admission.

Undeploy Service

To undeploy a service from ECloud, a new manifest must be created in order to trigger the action, providing the URN of the deployment. This URN is obtained from admission where the service is deployed. The manifest must be placed into /integration-test/manifest, and could be as follows:

{
  "action": "undeploy",
  "deploymentURN": "eslap://c2netproject/services/echoTester/1_0_1"
}

If the un-deployment was successfully executed, then a new .json is created in /integration-test/logs folder containing the response from ECloud admission.

Unregister Component

To unregister a component from ECloud, a new manifest must be created in order to trigger the action, providing the URN of the component. The manifest must be placed into /integration-test/manifest as follows:

{
  "action": "unregister",
  "componentURN": "eslap://c2netproject/components/cfeTester/1_0_1"
}

If the un-register was successfully executed, then a new .json is created in /integration-test/logs folder containing the response from ECloud admission.

An error will be thrown if you try to unregister a component which is already deployed. You will need to undeploy it first.

Unregister Service

To unregister a service from ECloud, a new manifest must be created in order to trigger the action, providing the URN of the service. The manifest must be placed into /integration-test/manifest as follows:

{
  "action": "unregister",
  "serviceURN": "eslap://c2netproject/services/echoTester/1_0_1"
}

If the un-register was successfully executed, then a new .json is created in /integration-test/logs folder containing the response from ECloud admission.

An error will be thrown if you try to unregister a component which is already deployed. You will need to undeploy it first.

Get Logs

To get a list of the logs generated by ECloud, you can create a new manifest in order to trigger the action, providing the URN of the deployment. The manifest must be placed into /integration-test/manifest as follows:

{
  "action": "logs",
  "deploymentURN": "slap://c2netproject/deployments/20170201_120854/87ce49ea"
}

If getting the logs was successfully executed, then a new .json is created in /integration-test/logs with the response and a new file .json.gz containing the logs to be visualized in Kibana.

Execute Test

Take a look to the Quick Start Guide. In short this section will be extended.

Apendix

AdmissionResponse

{
     "success": true,
     "message": "Bundle registration finished with no errors.",
     "data": {
       "successful": [
       ...
       ],
       "errors": [],
       "deployments": {
         "errors": [],
         "successful": [
           {
             "deploymentURN": "slap://c2netproject/deployments/YYMMDD_hhmmss/xxxxxxxx",
             "topology": {
               "service": "eslap://c2netproject/services/serviceName/version",
               "roles": {
                 "role1": {
                 ...
                 },
                 "sep_service": {
                    ...
                   "entrypoint": {
                     "secrets": {},
                     "sslonly": false,
                     "domain": "my-domain.osdmz.iti.es",
                     "instancespath": false
                   }
                 }
               }
             }
           }
         ]
       }
     }
   }