Component description

The "Provider SLA manager" -or briefly "P-SLAM"- is the Contrail component responsible for SLA negotiation and enforcement at Provider level. It is made of two main modules: a negotiation module that handles the required SLA negotiation steps with the F-SLAM (initiate negotiation, negotiation, create agreement), and an enforcement module that enforces the agreement terms once the SLA has been agreed. The Contrail P-SLAM is deployed as a set of OSGI modules inside a customized version of the SLA@SOI platform.

Resources used

• Contrail-customized SLA@SOI platform
• VEP
• Provisioning Manager
• Monitoring component
• Network ports 8080, 3306, 5005, 5672, 7077, 4444

Configuration

The following prerequisites must be satisfied before proceeding with the configuration of the component:

• A working SLA@SOI platform, in the version customized for Contrail, including all the required software dependencies. Note that the P-SLAM packages comes already with all the auxiliary software needed to work, including the customized version of SLA@SOI with a default configuration for P-SLAM (if for some reasons you want to do the installation by yourself, follow these SLA@SOI installation instructions).
• A VEP instance up & running. For testing purposes, a mocked VEP running on localhost:4444 can be used.

AMQP bus configuration

Configure the AMQP bus parameters (username, password, host, virtualhost) in:
$SLASOI_HOME/contrail-slamanager/provisioning-adjustment/eventbus.properties
Example (here username=slasoi, password=slasoi, host=10.15.5.52, vistualhost=/slasoi):
amqp_username=slasoi
amqp_password=slasoi
amqp_virtualhost=/slasoi
amqp_host=10.15.5.52
amqp_port=5672
amqp_resource=ProvisioningEventReader
amqp_pubsubservice=10.15.5.52
amqp_service=10.15.5.52
xmpp_channel=contrail

VEP configuration

The POC module of the SLAM requires a VEP endpoint to compute the available resources to negotiate.
VEP connection parameters are provided in the following file:
$SLASOI_HOME/contrail-slamanager/planning-optimization/planning_optimization.properties
Note: in the default configuration, $SLASOI_HOME=/opt/contrail/sla-at-soi/osgi-config

The file must contain the following parameters:
vep-username = username
vep-address = ipaddress
vep-port = port
vep-base-path = basepath ( e.g. api/cimi/ )
trustStore= keystore location
trustStorePassword= keystore password
the previous parameters allow to configure respectively: username, ip address, port, base path on which the vep is located, keystore location and password. If no VEP installation is available, it is possible to use a mock version of VEP provided by the package vepMock. Since vepMock doesn't implement security (only http) you should comment the last two lines (#trustStore, #trustStorePassword) inside the configuration file.

Provisioning Manager Endpoint configuration

Configure the URI_base variable, containing the Provisioning Manager endpoint, in file:
$SLASOI_HOME/contrail-slamanager/provisioning-adjustment/provisioning_adjustment.properties

OVF configuration

Configure the ovf_repo_path variable, containing the system path where to find the OVFs, in file:
$SLASOI_HOME/contrail-slamanager/provisioning-adjustment/provisioning_adjustment.properties
Users can specifies only filename to reference an OVF file inside the SLA Template, the PSLAM will try to search it inside the ovf_repo_path configured.

Prerequisites for SLAM usage

The following prerequisites must be satisfied in order to use P-SLAM:

• An SLA User created in SLA@SOI by using the (Contrail customized) createUser service
• A VEP instance up & running. Only for testing purposes, you may want to run a mocked VEP.

Starting and stopping P-SLAM

To start P-SLAM, use the startup script provided in the customized SLA@SOI installation, by default in /opt/contrail/sla-at-soi/
./start.sh

The script starts the Equinox OSGI framework, containing the SLA@SOI bundles and P-SLAM ones, and the syntax converter (a SLA@SOI component). If started successfully, a message containing the P-SLAM endpoint, similar to this, will appear in the OSGI console:
17:16:24,007 INFO  [SpringOsgiExtenderThread-47   ] ail.provider.main.beans.SkeletonSLAMBean  -
        *** :: start :: SkeletonSLAMBean >>
                [ID]                  ='CONTRAIL-SLAMANAGER-1-1'
                [EPR]                 ='http://10.15.5.116:8080/services/contrailNegotiation?wsdl'
                [GroupID]             ='GLOBAL'
                [wsPrefix]            ='contrail'
                [Gslam-services]      ='org.slasoi.gslam.main.activator.impl.GenericSLAManagerUtilsImpl@1c2b949'
                SLATemplateRegistry   ='org.slasoi.gslam.templateregistry.SLATemplateRegistryImpl@116610b'
                SLARegistry           ='org.slasoi.gslam.slaregistry.impl.SLARegistryImpl@3d3ea9'
                ProtocolEngine        ='org.slasoi.gslam.protocolengine.ProtocolEngineServices@dcf88e'
                SyntaxConverters      ='
                                SLASOISyntaxConverter=org.slasoi.gslam.syntaxconverter.SyntaxConverter@1424fcc
                Authorization         ='org.slasoi.gslam.core.authorization.BasicAuthorization@84f45e'
                ServiceAdvertisement  ='org.slasoi.sa.pss4slam.ServiceAdvertisementBroker@1e76a9'
                MonitorManager        ='org.slasoi.gslam.monitoring.manager.impl.MonitoringManager@c76b7d'
                PlanningOptimization  ='org.ow2.contrail.provider.poc.impl.PlanningOptimizationImpl@61fdcb'
                ProvisioningAdjustment='org.ow2.contrail.provider.pac.impl.ProvisioningAdjustmentImpl@15d3444'

Also, the bundles involved with provider SLA management are the last five (contrail* + ovf-parser-bundle). They must be all in ACTIVE state:
167     ACTIVE      contrail-core_0.1.0.SNAPSHOT
168     ACTIVE      contrail-slam4osgi_0.1.0.SNAPSHOT
169     ACTIVE      contrail-poc_0.1.0.SNAPSHOT
170     ACTIVE      contrail-pac_0.1.0.SNAPSHOT
171     ACTIVE      ovf-parser-bundle_1.0.0.SNAPSHOT

To stop P-SLAM, type "close" from the OSGI console:
...
171     ACTIVE      contrail-pac_0.1.0.SNAPSHOT
172     ACTIVE      ovf-parser_1.0.0.SNAPSHOT
osgi> close

Public API - provider-sla-manager

List of Contrail provider SLA manager sections:

• Negotiation
• Querying SLAs
• Enforcement

Section: Negotiation

Negotiation process is made of 3 steps:

• initiateNegotiation 
• negotiation 
• createAgreement

Each step is performed by the customer (in Contrail, it is the Federation) by invoking web services calls.

Web service URL

The HTTP port of the web services is 8080 and the endopoint for the SOAP request is the following:
/services/contrailNegotiation?wsdl
The URL is the same for all the 3 steps.
Example of URL (here 10.15.5.118 is the server where SLA@SOI platform runs):
http://10.15.5.118:8080/services/contrailNegotiation?wsdl

initiateNegotiation web service

Description

Initiate a new SLA negotiation.

Parameters

• slaTemplate: The SLA template chosen by the customer. Customer and Provider actors are identified in the SLA template itself, inside the SLA@SOI Party element.
  • Provider endpoint. In the enclosed SLA template, the Provider endpoint (value of "http://www.slaatsoi.org/slamodel#gslam_epr" SLA@SOI key) must match with the endpoint in use. The Provider party is identified by the SLA@SOI "http://www.slaatsoi.org/slamodel#provider" Role.
    Example for an P-SLAM running on host 10.15.5.118:
    <slasoi:Party>
    <slasoi:Text/>
    <slasoi:Properties>
    <slasoi:Entry>
    <slasoi:Key>http://www.slaatsoi.org/slamodel#gslam_epr</slasoi:Key>
    <slasoi:Value>http://10.15.5.118:8080/services/contrailNegotiation?wsdl</slasoi:Value>
    </slasoi:Entry>
    </slasoi:Properties>
    <slasoi:ID>ContrailProvider</slasoi:ID>
    <slasoi:Role>http://www.slaatsoi.org/slamodel#provider</slasoi:Role>
    </slasoi:Party>

Return Value

• return: A hexadecimal code representing the SLA negotiation session ID.

Request example

Response example

negotiate web service

Description

Negotiate a SLA.

Parameters

• slaTemplate: The SLA template proposed by the customer. It is the same slaTemplate used in initiateNegotiation web service.
• negotiationID: The negotiation session ID returned by the invocation of initiateNegotiation web service. 

Return Value

• return: A list of SLA Template counter-offers. Each SLA template represents the counter offers of the provider.

Request example

Response example

Web service: createAgreement

Description

Creates a new SLA agreement, based on an input SLA template. If the request is successful, the new SLA is saved in the SLA registry.

Parameters

• slaTemplate: The final SLA template choosen by the customer. It has to be one of the offers returned by the negotiate service.
• negotiationID: The negotiation session ID returned by the invocation of initiateNegotiation API. 

Return Value

• return: The agreed SLA. 

Request example

Response example

Section: Querying SLAs

Agreed SLA can be queried by giving as input parameter a SLA Id or a User Id:

• getSLA 
• getSLAbyUserId 

Web service URL

The HTTP port of the web services is 8080 and the endopoint for the SOAP request is the following:
/services/BusinessManager_Reporting?wsdl
The URL is the same for both services.
Example of URL (here 10.15.5.118 is the server where SLA@SOI platform runs):
http://10.15.5.118:8080/services/BusinessManager_Reporting?wsdl

Web service: getSLA

Description

Retrieve a SLA given a SLA Id.

Parameters

• slaId: The Id of the registered SLA. The ID is included in the SLA itself: the caller of the createAgreement service can retrieve from the UUID field in the SLA contained in the response. 

Return Value

• return: The SLA if the SLA is found, otherwise an error message.

Request example

Response example

Web service: getSLAbyUserId

Description

Retrieve the list of SLAs agreed by a given user.

Parameters

• userId: The Id of the user who negotiated the SLA(s). 

Return Value

• return: The SLA list if any, otherwise an error message.

Request example

Response example

Section: Create Party

This section desribes how to insert a new customer into the P-SLAM database. The customized SLA@SOI framework expose a SOAP web service call to create a new Party. 

Web service URL

The HTTP port of the web services is 8080 and the endpoint for the SOAP request is the following:
/services/BusinessManager_Party?wsdl
Example of URL (here 10.15.5.118 is the server where SLA@SOI platform runs):
http://10.15.5.118:8080/services/BusinessManager_Party?wsdl

Description

Create a new Customer that will be managed by P-SLAM.

Parameters

• type: please specify 'I' ("Individual")
• partyId: SLA@SOI ID of the customer being created
• currencyId: please use '1' (EUR) for the SLA@SOI currency
  Other input fields names (name, address, language, credentials, etc.) are self-explanatory (see example below).

Return Value

• return: The result of the call.

Request example

Response example

Section: Enforcement

This section explain how to dinamically configure PSLAM's enforcement policy. The enforcement task is performed through the use of DROOLS as rules engine. DROOLS support is already included inside the SLA@SOI framework and the P-SLAM specifies a rule to manage violation messages coming from the monitoring component. The rule which state this behavior is located under:

/opt/contrail/sla-at-soi/osgi-config/contrail-slamanager/provisioning-adjustment/basic_communication_rules_Contrail.drl.

The following is an example of rule:

The previous rule defines two different behaviors due to two different incoming messages. In case of warning message will be executed the EventWarningCustomActionHandler that will launch a custom action previously defined. While in case of violation message will be executed the EventViolationFederationForwardingHandler  that will forward the message to the federation channel.
The channel where to forward the message is configured inside the properties file:

/opt/contrail/sla-at-soi/osgi-config/contrail-slamanager/provisioning-adjustment/provisioning_adjustment.properties 

and more precisely on the property amqp_federation_forwarding_channel (i.e. INFRASTRUCTURE_FEDERATION_FORWARDING_EVENT_CHANNEL). The property enable_forward_violation_message (true/false) allow P-SLAM to enable or disable the operation of forwarding to the federation (i.e for testing purpose).

Finally, you may want to write your own Java class implementing your enforcement policy. The class must extend the abstract Java class EventHandler and must implement the method

public abstract void process() 

which will contain the code to be executed giving a particular event.  

Custom Action

The previously described handler EventWarningCustomActionHandler will execute a "Custom Action" previously defined by the customer.
 A customer may want to define a specific behavior due to a particular event (i.e a warning message from the monitoring component that notify a "likely" forthcoming violation of a previously agreed term). P-SLAM allow customer to write a Java class that will be executed on that particular event. The triggering condition, along with Java classname ad method to be performed, are referenced inside the SLA Template as an Agreement Term.
Here is an example of custom action referenced inside SLA Template:

which declare that the method manageADD(String virtualSystem, String number) of the class  org.ow2.contrail.provider.pac.action.ViolationAction should be executed when the vm_cpu_load of the virtual system specified by VM_of_type_ubu1 is greater than 1.5 .