Multiple enforcement mechanisms, Multi cloud control configuration - tuwiendsg/rSYBL GitHub Wiki

rSYBL can control services which have different service parts (e.g., service topologies/composite components) deployed on different cloud providers. Moreover, rSYBL can also use user-defined control, which can be defined following the steps in the next section, in order to control cloud services.

An example of a client which follows this entire lifecycle, with two clouds, as presented in the figure below, is available here. The description of the cloud service together with its requirements stays the same, for the case the cloud service is deployed on two clouds with similar functionalities.

MultipleEnforcementPlugins = flexiant:at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.flexiant.EnforcementFlexiantAPI, openstack:at.ac.tuwien.dsg.rSybl.cloudInteractionUnit.enforcementPlugins.openstack.EnforcementOpenstackAPI

This way, we say that we will refer to the EnforcementFlexiantAPI as flexiant, and to EnforcementOpenstackAPI as openstack, and we will use them both.

However, there are some differences in terms of effects description and deployment description. The single difference, next to adding extra plugins in config.properties, is that when specifying capabilities of different nodes, one needs to specify which enforcement mechanism comes from which plugin:

<AssociatedVM IP="109.231.122.250" UUID="131627fe-d5f3-3518-8bf5-7d16a932df8c"/>

<AssociatedVM IP="109.231.122.251" UUID="9c99d99b-b2c4-30ee-a87f-67e7370291ad"/>	

<ElasticityCapability Name="flexiant.scaleIn"/>

<ElasticityCapability Name="flexiant.scaleOut"/>

<AssociatedVM IP="10.99.0.91"/>

<ElasticityCapability Name="openstack.scaleIn"/>

<ElasticityCapability Name="openstack.scaleOut"/>

The description above is normally introduced not by the user, but by the deployment/configuration framework (e.g., SALSA) as the deployment should be done automatically.