Chapter 5 Adapting Applications for Sun OTP

You need to create the provisioning and management plug-ins to adapt your application to Sun OTP. A plug-in is a collection of plans and components. A plan orchestrates deployment of multiple components.

The following topics are discussed:

• Developing N1 SPS Plans for NEP Application Provisioning

• Developing Sun Cluster HA Agents for NEP Application Management

Developing N1 SPS Plans for NEP Application Provisioning

Refer to Sun N1 Service Provisioning System 5.2 Plan and Component Developer’s Guide to create components and plans for NEP applications.

The three options of adapting your application for application provisioning are as follows:

Calling Existing Application Installers from N1 SPS

Moving an Existing Application Installer Code to an SPS Component

Using Native N1 SPS Provisioning Features

Calling Existing Application Installers from N1 SPS

If the installation script for your application already exists, you can create a component template and call the installation script from the component template.

Example

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns='http://www.sun.com/schema/SPS' 
name='DeployMyComponent'
version='5.0'
description='Deploy and configure My Component'
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
path='/com/sun/foobar'
author='OEM Platforms'
softwareVendor='Sun Microsystems'
xsi:schemaLocation='http://www.sun.com/schema/SPS component.xsd'>

<extends>
<type name='system#container'></type>
</extends>

<varList>
   <var name="bashShell" modifier="FINAL" default="/usr/bin/bash"/>
   <var name="installPath" default="/opt"/>
</varList>

<installList>
   <installSteps name="deployMyComponent" access="PUBLIC">

    <execNative userToRunAs='root' timeout='7200'>
      <inputText><![CDATA[

      #run installer
      /script_directory/installer.sh -p param1 -s param2
      #check for errors
      RET=$?; if [ $RET != 0 ]; then exit $RET; fi

      ]]></inputText> <exec cmd=":[bashShell]"></exec>
    </execNative>
   </installSteps>
</installList>
</component>

Moving an Existing Application Installer Code to an SPS Component

You can also copy the application deployment logic from the installation script of your application and paste the logic into a provisioning component. This option can be used for a tighter integration with Sun OTP provisioning service. In the following example, the application installation script is embedded in its provisioning component.

Example

<?xml version="1.0" encoding="UTF-8"?>
<component xmlns='http://www.sun.com/schema/SPS' name='InstallMyComponent'
  version='5.2.4'
  description='Install My Component'
  xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
  author='OEM Platforms' softwareVendor='Sun Microsystems'
  path='/com/sun/examples'
  xsi:schemaLocation='http://www.sun.com/schema/SPS component.xsd'>

<extends>
<type name='system#container'></type>
</extends>

<varList>
<var name='shell' modifier='FINAL' default='/usr/bin/bash'></var>
<var name='installPath' default='/opt' modifier='FINAL'></var>
<var name="mediaDirectory" default=":[component:/com/sun/example:mediaDirectory]"/>
<var name='postcheck' default='no' prompt="Mark yes if post check required"></var>
</varList>
<installList>
     <installSteps returns='false' name='InstallMyComponent' requireLocking='true'>
       <execNative userToRunAs='root' timeout='7200'>
           <inputText><![CDATA[

# Example of product installation:
# -step 1: initial checks (does product bundle exist?)
# -step 2: extraction of bundle into temporary directory
# -step 3: invocation of product installer
# -step 4: (optional) installation post check (was product installed fine?)
# -step 5: temporary files clean up

# 1: initial checks
scriptPath=:[mediaDirectory]/productName
if [ ! -d $scriptPath ]; then
echo "Error: $scriptPath does not exist"
exit 1
fi
if [ ! -f ${scriptPath}/productName.jar ]; then
echo "Error: productName.jar does not exist"
exit 1
fi

# 2a: copy bundle to tmp
mkdir -p /tmp/install/productName
cp ${scriptPath}/productName.jar /tmp/install/productName
cd /tmp/install/productName

# 2b: extraction of bundle contents
jar xf productName.jar
rm -f productName.jar

# 3: invoke installer
java -cp /tmp/install/productName com.company.product.Boot -p param1 -d param2 -i :[installPath]
RET=$?; if [ $RET != 0 ]; then exit $RET; fi

# 4: post check
if [ "yes" = :[postcheck] ]; then
out=`java -cp /tmp/install/productName com.company.product.diagnostics checkInstallation -p param1 \
-d param2 -i :[installPath] | grep "Status=OK"`
RET=$?; if [ $RET != 0 ]; then exit $RET; fi
fi

# 5: cleanup
cd /
rm -rf /tmp/install/productName


      ]]></inputText> 
      <exec cmd=':[shell]'></exec>
    </execNative>
   </installSteps>
</installList>
</component>

The embedded code can be any interpreted shell code or Java code. The shell code can be specified by specifying the value for the cmd attribute in the exec element. The embedded Java code can be specified by specifying the execJava element.

Using Native N1 SPS Provisioning Features

To fully benefit from Sun OTP application provisioning service features, the target application deployment can be redesigned using native Sun OTP provisioning components. This can be done by mapping the application deployment elements to native provisioning components. Based on your application distribution model, these elements could be packages (Solaris SVR4, Linux RPM and Deb) or archives (such as zip, tar, jar, ear) or even individual files (like a library, a kernel module, or scripts).

The following sample code demonstrates package-based installation.

Example 1

<installList>
    <installSteps returns='false' name='default' requireLocking='true'>
        <execNative timeout='1800'>
            <inputText><![CDATA[>
                echo "Executing Pre-Install procedures before resource deployement"
                echo "This will be installed into: :[installPath]"
            ]]></inputText>
                   <exec cmd='/bin/sh'></exec>
        </execNative>
            <deployResource></deployResource>
        <execNative timeout='1800'>
            <inputText><![CDATA[
                 echo "Executing Post-Install procedures after resource deployement"
                 pkgadd -d :[installPath] SampleAppPkg
            ]]></inputText>
                   exec cmd='/bin/sh'></exec>
        </execNative>
    </installSteps>
</installList>

The following sample code demonstrates package-based uninstallation.

Example 2

<uninstallList>
    <uninstallSteps returns='false' name='default' requireLocking='true'>
        <execNative timeout='1800'>
            <inputText><![CDATA[>
                echo "Executing Pre-Uninstall procedures before resource undeployement"
            ]]></inputText>
                   <exec cmd='/bin/sh'></exec>
        </execNative>
            <undeployResource></undeployResource>
        <execNative timeout='1800'>
            <inputText><![CDATA[
                 echo "Executing Post-Uninstall procedures after resource undeployement"
                 yes | pkgrm SampleAppPkg
            ]]></inputText>
                   exec cmd='/bin/sh'></exec>
        </execNative>
    </uninstallSteps>
</uninstallList>

Refer to the following guides to create plans, components, and plug-ins using N1 SPS.

• Sun N1 Service Provisioning System 5.2 Plan and Component Developer’s Guide

• Sun N1 Service Provisioning System 5.2 Operation and Provisioning Guide

• Sun N1 Service Provisioning System 5.2 Plug-in Development Guide

• N1 Service Provisioning System 5.2.1 Plug-In Collection

• Best Practices Walkthrough document at http://www.sun.com/bigadmin/hubs/sysmgmt/learn/training.jsp

• Developer Guidelines document at http://www.sun.com/bigadmin/hubs/sysmgmt/learn/training.jsp

Developing Sun Cluster HA Agents for NEP Application Management

You need to create the management agents for your application to use the Sun OTP availability service. You can develop agents using agent builder, scripts, and C/C++.

Developing Agents Using Agent Builder

Sun Cluster agent builder is included in Sun OTP. The agent builder allows you to specify information about your application and the kind of resource type (scalable or failover) that you want to create.

You need to provide start, stop (optional), validate (optional), and probe (optional) commands for your application. Agent builder automatically generates an agent package that can be used to put your application under Sun OTP management service control.

For more information on developing agents using agent builder, refer to Sun Cluster Data Services Developer’s Guide for Solaris OS.

Developing Agents Using Scripts and C/C++

Refer to the following guides to develop agents using scripts and C/C++.

• Sun Cluster Data Services Developer’s Guide for Solaris OS

• Sun Cluster 3.2 Data Services Collection for Solaris OS (SPARC Platform Edition)

• Sun Cluster Data Services Planning and Administration Guide for Solaris OS