Overview

Apache Stratos supports many Infrastructure as a Service (IaaS) platforms; EC2, OpenStack, vCloud, CloudStack, Docker etc. However, setting up an IaaS or purchasing a public IaaS service is an overhead for contributors and people who would like to tryout Stratos. Furthermore, setting up a local IaaS needs a considerable amount of hardware resources and purchasing an online IaaS account involves costs. Due to these barriers the Stratos community was not able to implement automated integration tests, bring in new contributors and allow people to tryout Stratos with the least amount of effort.

However, this problem was solved to a great extent when Stratos introduced Linux Container support with Docker/Kubernetes. Nevertheless, setting up a Kubernetes cluster also requires several virtual/physical machines and setting up a Puppet master (or any other orchestration platform) is an overhead. Furthermore, with the introduction of the Composite Application feature for grouping cartridges, this issue got aggravated due to the complexity of the logic implemented and the time it took to verify each functionality with the IaaS platforms.

As a solution to this problem, Apache Stratos has introduced the Mock IaaS feature, which could simulate the basic features that Stratos requires from an IaaS.

Generally, the Mock IaaS resides in the Cloud Controller and is started in a single Java virtual machine (JVM). However, in cloud bursting and Stratos product clustering scenarios the Mock IaaS needs to be run as a separate product in a distributed setup, which uses multiple JVMs. Therefore, to support this the Mock IaaS has been exposed as a REST service to be able to create a separate server profile. Thereby, this allows the Mock IaaS to be started as a separate product, so that the Cloud Controller can be configured to communicate with the Mock IaaS via the Mock IaaS API.

 For more information on how to start Stratos on a Mock IaaS, see Working with the Mock IaaS.

Architecture

The following diagram illustrates the component architecture of the Mock IaaS:

Stratos IaaS Interface

Stratos provides an abstraction layer for implementing support for Infrastructure as a Service solutions. This is a generic interface that includes the following features:

In Apache Stratos 4.0.0 release the Stratos IaaS interface did not include some of the methods for interacting with the IaaS. Instead, those methods were directly invoked via the jclouds compute service API. With the introduction of the Mock IaaS all the methods required to communicate with the IaaS were moved to the IaaS interface and jclouds specific logic were moved to a separate class named JcloudsIaas. Now, this IaaS interface is implemented by the Mock IaaS client and jclouds IaaS client (JcloudsIaas). The jclouds IaaS client has been further extended by EC2, OpenStack, vCloud, CloudStack, Docker providers.

How it works?

The mock IaaS service simulates the lifecycle of an instance using a thread. Each instance will have a separate thread, which publishes the instance status events to the message broker and health statistics to the Complex Event Processor (CEP). When a mock member thread is started, it will publish the Instance Started event to message broker and in several seconds it will publish the Instance Activated event. Thereafter, the health statistics publisher will be started. It will read statistics from a singleton health statistics map, which is updated by the health statistics generator.

Health statistics generator updates the health statistics map according to the statistics patterns defined in the Mock IaaS configuration. The following sample Mock IaaS configuration, which can be found in the <apache-stratos-4.1.x-SNAPSHOT>/repository/conf/mock-iaas.xml file, illustrates how these patterns could be defined for different cartridges. 

<mock-iaas enabled="true">
   <health-statistics>
       <cartridge type="tomcat">
           <!-- factor:memory-consumption|load-average|request-in-flight-->
           <!-- mode:loop|continue|stop -->
           <!-- Mode defines the action needs to be taken after the last sample value:
                loop: start from beginning
                continue: continue the last sample value
                stop: stop publishing statistics -->
           <pattern factor="memory-consumption" mode="continue">
               <!-- Sample values -->
               <sampleValues>20,30,40,50,60,70,50,40,30,20</sampleValues>
               <!-- Duration of each sample value in seconds -->
               <sampleDuration>60</sampleDuration>
           </pattern>
           <pattern factor="load-average" mode="continue">
               <!-- Sample values -->
               <sampleValues>20</sampleValues>
               <!-- Duration of each sample value in seconds -->
               <sampleDuration>60</sampleDuration>
           </pattern>
       </cartridge>
   </health-statistics>
</mock-iaas>

In the above sample, a health statistics generation pattern has been defined for the Tomcat cartridge. Similarly, you can define multiple health statistics generation patterns for different cartridges. It is possible to define three different auto-scaling factors (memory-consumption, load-average and request-in-flight) under each cartridge. The mock health statistics generator will generate statistics for each factor for the given cartridge and update the central health statistics map. In each pattern mode, the attribute defines the action that needs to be taken once the last sample value is reached. If this is set to loop, the mock health statistics generator will loop back to the first value. If it is set to continue, the last sample value will be continued. If it is set to stop, the health statistics generation process will be stopped and eventually the health statistics publishing process will also be stopped. Finally, the members in that cluster will become faulty.