OpenClovis Product Documentation

Revision as of 16:22, 20 February 2012

http://www.buyxanaxonlinepill.com/ buy xanax online - generic xanax online

http://www.buyxanaxonlinepill.com/ purchase online generic xanax - xanax buy online

http://www.buyxanaxitem.com/ buy cheap xanax - buy xanax online no prescription

Generating the csa101 Code

In this step we generate the source code for our example. The code that will be created is the framework code that handles all of the low level functionality provided by SAFplus Platform.

To generate the source code go to the Project menu and select Generate Source. Several progress dialogs will appear and after a few seconds code generation will be complete.

The source code and configuration XML files are generated and placed in subdirectories of the Project Area Location that we specified in the New Project Wizard. You can review this location by using the Project > Properties menu to get to the Project Properties dialog and then selecting Clovis System Project in the left hand pane.

You can review the generated code from within the SAFplus Platform IDE. To do this go to the Clovis Workspace pane and expand the SampleModel node. The node tree should look like the following.

Clovis Workspace Code Tree

The code of particular interest to our example is in the SampleModel/src/app/csa101 branch of the tree. This is the code for our csa101 example. The csa101 example consists of two C modules (clCompAppMain.c and clCompCfg.c) and two header files. There is also a make file that will be used for building the application. The clCompAppMain.c file implements our 'Hello World!' application.

If you run code generation a second time you will be presented with a dialog box asking if you would like to make a backup copy of the existing source code before proceeding. You can answer No to this dialog.

Customizing the csa101 Code

While the code that was generated in the previous section can be built and run we want to make some changes to it so that we can easily see what our example is doing. For our example we will be changing one source file (clCompAppMain.c) and two make files.
In a real production situation this is the point where you would customize the code to perform the specific tasks of your product.

You will notice in the C file that there are several places where you see the following comment block.

 /*
   ---BEGIN_APPLICATION_CODE---
 */

 // ...

 /*
   ---END_APPLICATION_CODE---
 */
 

Makefiles have a similar convention but with a slightly different syntax.

 # ---BEGIN_APPLICATION_CODE---

 # ---END_APPLICATION_CODE---
 

These are sections of the file where it is safe to enter custom application code without having to worry about that code being overwritten if you were to again perform Generate Source for your model. This is important since the typical development cycle is an iterative process where you will return to the IDE to make modifications to your model.

To simplify the process of building and running the csa101 example, OpenClovis, Inc. has already made the necessary code customizations and shipped this code with the SAFplus Platform SDK. At this point you can simply replace the generated source files with these customized versions to avoid typing in the changes. We will go over each customization below and explain what was done.

To replace the generated files with the customized versions shipped with the SAFplus Platform SDK follow these instructions.
The sample applications containing the csa101 example can be found under the installation directory at <install_dir>/sdk-5.0/src/examples/eval. We will refer to this directory in the remaining of this section as <eval_dir>.

1. Exit the SAFplus Platform IDE using the File > Exit menu item. If you are prompted to save changes before exiting answer yes.
2. Navigate to the source code work area.

   # cd /home/clovis/projectarea1/ide_workspace/SampleModel/src/app

3. Using your favorite editor open the file Makefile that resides in this directory. This is the application make file.
4. Add the following line to this file within the first BEGIN_APPLICATION_CODE and END_APPLICATION_CODE comment block.

   SUBDIRS += ev

   This will instruct the build process to build our custom output library.

5. Save this file and exit the editor.
6. Execute the following command to copy the output package to our working area.

   # cp -r <eval_dir>/src/app/ev .

7. Navigate to the component code work area.

   # cd csa101

8. Execute the following command to copy the csa101 source code.

   # cp <eval_dir>/src/app/csa101/clCompAppMain.c .

9. Execute the following command to copy the component make file.

   # cp <eval_dir>/src/app/csa101/Makefile .

10. Restart the SAFplus Platform IDE.

    # cl-ide

Customizing clCompAppMain.c

The clCompAppMain.c file is the C module which will implement our 'Hello World!' behavior. We have to make changes in several parts of this file.
If you copied the files as instructed in the section above then these changes have already been made to the files. Use this section to review and understand the changes.

1. In the include section of this file we have added a new include for ev.h. This refers to a special output library that we copied to our work area in the previous section. This output library is used to redirect output from the application to a component specific log. This is purely cosmetic but it will allow us to easily monitor what is happening when we run our example. (The following code begins at line 44 of the source file.)

   clCompAppMain.c
   /* ---BEGIN_APPLICATION_CODE--- */ #include "clCompAppMain.h" #include "../ev/ev.h" /* ---END_APPLICATION_CODE--- */

   
   

2. Next we define a couple of static variables that will keep track of the state of our application and a function to aid in showing when the application is running. (The following code begins at line 79 of the source file.)

   clCompAppMain.c
   /* ---BEGIN_APPLICATION_CODE--- */ static int running = 0; static int exiting = 0; static char* show_progress(void) { static char bar[] = " ."; static int progress = 0; /* Show a little progress bar */ return &bar[sizeof(bar)-2-(progress++)%(sizeof(bar)-2)]; } /* ---END_APPLICATION_CODE--- */

   The running flag will be used to indicate whether the current application is active or suspended while exiting is a flag that indicates that the main() function returns, causing the exit of the application.

   The function show_progress returns a pointer to a c string with a number of spaces followed by a '.' character. The number of spaces in the string cycles from zero to an upper bound. This is used later on to provide visual indication of the progress of the application's output.

3. Next we have added a function hello_func to print the output. (The following code begins at line 118 of the source file.)

   clCompAppMain.c
   void *hello_func(void *unused) { while (!exiting) { if (running) { clprintf(CL_LOG_SEV_INFO, "csa101: Hello World! %s\n", show_progress()); } sleep(1); } return NULL; }

   Notice the while loop condition. This function uses the exiting variable that was initialized to 0. The loop will keep running until exiting is set to non-zero. The if condition within the while loop checks the value of the running variable. The work of the application: printing "Hello World!" along with the progress indicator will only be done when the running variable is set non-zero. Next the command sleep(1) simply sleeps for a second so as not to fill log files too quickly or completely swamp the CPU.

   When exiting becomes non-zero, we return from the function.

4. Next we have added a function to initialize the special output library mentioned earlier (which is at line 245 in the source file).
5. Next we create a thread and call the function hello_func in the new thread context. (The following code begins at line 252 of the source file.)

   clCompAppMain.c
   /* * ---BEGIN_APPLICATION_CODE--- */ clprintf(CL_LOG_SEV_INFO, "csa101: Instantiated as component instance %s.\n", appName.value); clprintf(CL_LOG_SEV_INFO, "%s: Waiting for CSI assignment...\n", appName.value); rc = clOsalTaskCreateDetached("hello_thread", CL_OSAL_SCHED_OTHER, CL_OSAL_THREAD_PRI_NOT_APPLICABLE, 0, hello_func, NULL); CL_ASSERT(rc == CL_OK); /* * ---END_APPLICATION_CODE--- */

6. Next we indicate to our app when we are exiting. (The following code begins at line 284 of the source file.)

   clCompAppMain.c
   /* * ---BEGIN_APPLICATION_CODE--- */ exiting = 1; clEvalAppLogStreamClose(gEvalLogStream); /* * ---END_APPLICATION_CODE--- */

   We set the exiting variable to 1. This will cause the loop in our hello_func function to exit.

   
   

7. Next we will put in code to manage the state of our application. (The following code begins at line 453 of the source file.)

   clCompAppMain.c

   void clCompAppAMFCSISet(SaInvocationT invocation, const SaNameT *compName, SaAmfHAStateT haState, SaAmfCSIDescriptorT csiDescriptor) { /* * ---BEGIN_APPLICATION_CODE--- */ // ... /* * ---END_APPLICATION_CODE--- */ /* * Print information about the CSI Set */ clprintf (CL_LOG_SEV_INFO, "Component [%.*s] : PID [%d]. CSI Set Received\n", compName->length, compName->value, mypid); clCompAppAMFPrintCSI(csiDescriptor, haState); /* * Take appropriate action based on state */ switch ( haState ) { case SA_AMF_HA_ACTIVE: { /* * AMF has requested application to take the active HA state * for the CSI. */ /* * ---BEGIN_APPLICATION_CODE--- */ clprintf(CL_LOG_SEV_INFO, "csa101: ACTIVE state requested; activating service\n"); running = 1; /* * ---END_APPLICATION_CODE--- */ saAmfResponse(amfHandle, invocation, SA_AIS_OK); break; }

   clCompAppMain.c

   case SA_AMF_HA_STANDBY: { /* * AMF has requested application to take the standby HA state * for this CSI. */ /* * ---BEGIN_APPLICATION_CODE--- */ clprintf(CL_LOG_SEV_INFO, "csa101: New state is not the ACTIVE; deactivating service\n"); running = 0; /* * ---END_APPLICATION_CODE--- */ saAmfResponse(amfHandle, invocation, SA_AIS_OK); break; } case SA_AMF_HA_QUIESCED: { /* * AMF has requested application to quiesce the CSI currently * assigned the active or quiescing HA state. The application * must stop work associated with the CSI immediately. */ /* * ---BEGIN_APPLICATION_CODE--- */ clprintf(CL_LOG_SEV_INFO, "csa101: Acknowledging new state\n"); running = 0; /* * ---END_APPLICATION_CODE--- */ saAmfResponse(amfHandle, invocation, SA_AIS_OK); break; }

   clCompAppMain.c

   case SA_AMF_HA_QUIESCING: { /* * AMF has requested application to quiesce the CSI currently * assigned the active HA state. The application must stop work * associated with the CSI gracefully and not accept any new * workloads while the work is being terminated. */ /* * ---BEGIN_APPLICATION_CODE--- */ clprintf(CL_LOG_SEV_INFO, "csa101: Signaling completion of QUIESCING\n"); running = 0; /* * ---END_APPLICATION_CODE--- */ saAmfCSIQuiescingComplete(amfHandle, invocation, SA_AIS_OK); break; }

   We have modified the clCompAppAMFCSISet callback function to let our application know what to do when the state changes. In the case where the state changes to SA_AMF_HA_ACTIVE we set the running variable to 1. This will cause our application to begin printing the 'Hello World!' message. For any other state change we set the running variable to 0 which will cause the message to stop printing. For any state change we print out a message indicating the new state of the application.

   
   

8. The last change that we make is to indicate to our application when the component is being disassociated with the workflow. (The following code begins at line 588 of the source file.)

   clCompAppMain.c
   void clCompAppAMFCSIRemove(SaInvocationT invocation, const SaNameT *compName, const SaNameT *csiName, SaAmfCSIFlagsT csiFlags) { .... /* * Add application specific logic for removing the work for this CSI. */ /* * ---BEGIN_APPLICATION_CODE--- */ running = 0; /* * ---END_APPLICATION_CODE--- */ saAmfResponse(amfHandle, invocation, SA_AIS_OK); return; }

   In the clCompAppAMFCSIRemove callback function we indicate to our application that we are no longer running so that the while loop in the hello_func function stops printing our 'Hello World!' message.

Customizing the Component MakeFile

We have to make a small change to the component MakeFile so that it knows about our special output library during the build. To do this we add the following lines. This file is located in /home/clovis/projectarea1/ide_workspace/SampleModel/src/app

    # ---BEGIN_APPLICATION_CODE---

    SUBDIRS += ev

    # ---END_APPLICATION_CODE---

Customizing the Application MakeFile

We have to make sure that our special output library is built along with our application. To do this we change the line listing the sudirectories to make as follows. This file is located in the directory /home/clovis/projectarea1/ide_workspace/SampleModel/src/app/csa101.

    # ---BEGIN_APPLICATION_CODE---
    
    ...

    # Library added for demo console handling for the evaluation kit
    ASP_LIBS   +=  libeval.a

    # ---END_APPLICATION_CODE---

We are finished customizing our application code!

Building the csa101 Code

Now that we have finished customizing the code it is time to build it. The build process is launched using the Project > Build Project menu item. Once selected the Build Configuration dialog appears.

Build Configuration Details

The Build Configuration dialog is used to gather specific information about the build we are about to perform. Using this dialog you can rebuild the same model using different cross builds, or including different chassis managers. We don't have to make any changes to this dialog since the default settings make sense for our sample application.

If you have prebuilt the SAFplus Platform libraries then you can check the Use pre built SAFplus checkbox and include the location of the prebuilt libraries. For more information about pre-building SAFplus Platform libraries, see SAFplus Platform SDK User Guide.

The Include SNMP for North Bound Access control is checked by default. This just means that Net SNMP will be started along with our system. If you want end-to-end connectivity you will need to supply an SNMP Sub Agent and a MIB. See the SAFplus Platform SDK User Guide for more details.

In the Project menu if the Build Project entry is not highlighted, then click in the right pane i.e. Clovis Workspace pane and click the Project menu again. This not highlighting of the Build Project is because the Clovis Workspace is not selected properly because of moving focus to some other pane.

Click the OK button to begin the build. If this is the first time that the project is being built, or if you have made changes to any setting on this screen, you will initially see a progress dialog indicating that the project is being configured. The configuration step is setting up the project for building. After the configuration has completed you will see a progress dialog indicating that the code is being built.

Creating the csa101 Images

Making the csa101 images will create software packages that can be deployed on target machines to run the example. The process of creating images is launched using the Project > Make Images menu item. Once selected the Make Images Configuration dialog appears.

Make Images Configuration Details

The Make Images Configuration dialog is used to indicate information about the environment on which the images will be deployed. This information is used to tailor the images to run on that environment. Here we will make the following modificaiton.

• Enter a value for the Trap IP. This value specifies where the SNMP sub-agent will send traps at runtime. This field is optional but if specified must be a valid IP address. Enter a value of '127.0.0.1' in this field.
• Enter a value for the TIPC Net ID. This value represents a unique identifier used by TIPC to set up interprocess communication across the deployed OpenClovis SAFplus Platform cluster. This field is required and should default to '1340'.
• Check the Create Node Specific Images and Package Images into Tarballs check boxes. This will create tarballs of the images making them easy to deploy to various machines.
• The table on this dialog will hold a row for each node instance defined in the model. In our case this is only one...SCNodeI0. For each of these instances we can define the slot number in the chassis on which the node will run and the network interface that the node will use for communication. In our case enter '1' for the Slot Number and 'eth0' for the Network Interface.
• Click OK to begin the make image process. A dialog box will appear and after a few seconds the the make images process will be complete.

The images will be populated at <project_area>/target/SampleModel/images. Each node-specific image is provided as a directory containing the run-time files (binaries, libraries, prerequisites, and configuration files) as well as a tarball with the same content. e.g. For our model containing one node (SCNodeI0) the following files and directories are generated for deployment on the run-time system.

<project_area>
   |+target
       |+<model>
           |+images
               |+SCNodeI0
               |   |+bin
               |   |+etc
               |   |+lib
               |   |+modules
               |   |+share
               |-SCNodeI0.tgz

The rest of the steps in this example are all done from the command line so we can exit the IDE. To do this use the File > Exit menu item.

Deploying the csa101 Images

Now that the image has been built we must deploy it so that we can run and observe our example. Since we are assuming that the example will be run on the same machine as the images were built this is a fairly trivial exercise. Use the following steps to deploy the runtime image.

1. First we create a directory where we will install the image. In our case we will use /root/asp.

   # cd /root
   # mkdir asp
   

2. Next we navigate to that directory and untar the deployment package.

   # cd /root/asp
   # tar xzvf /home/clovis/projectarea1/target/SampleModel/images/SCNodeI0.tgz
   

The System Controller is now installed and ready to run.

If you were going to run the example on a machine other than the one where the images were built you would first copy the installation tarball to that machine before performing the above steps.

Running the csa101 Example

There are two parts to running the csa101 example. First we must start SAFplus Platform, and then we interact with the system components.

Starting SAFplus Platform

To start SAFplus Platform on System Controller node.

1. Open a shell.
2. Run the following commands

   # cd /root/asp
   # etc/init.d/asp start
   

This assumes that you are running the SAFplus Platform example on the same PC that you are executing these commands. If you are running SAFplus Platform on a different machine then you should first ssh to that machine before executing the commands.

If SAFplus Platform fails to start properly it could be due to the machine's firewall being enabled. SAFplus Platform will not run on a machine which has firewall enabled. See the Environment Related Observation section of the SAFplus Platform Release Notes for more information.

By default the network interface used by the Group Membership Service is set to eth0. During the make images phase of the tutorial we also set the ethernet interface for node SCNodeI0 to be eth0. During image generation these configuration parameters are written to two files in the deployment package.

• /root/asp/etc/clGmsConfig.xml
• /root/asp/etc/asp.conf

There may be an occasion where you want to switch this interface for a machine on which you are deploying. If you would like to switch this interface on a machine without having to go through the process of rebuilding and redeploying, you can edit these two files and change the 'eth0' references to the interface you would like to use.

Interacting with the System Components

Once SAFplus Platform is up and running the next step is to start csa101 by informing SAFplus Platform that it should start the application. The Evaluation System's model tells SAFplus Platform that csa101 is locked for instantiation. This means that the process will not be started when SAFplus Platform comes up. This method of starting csa's is used for the Evaluation System, allowing users to interact with csa's and clearly see their output/functionality. Usually this would not be the case with applications, where they would run when SAFplus Platform begins.

At this point it would help to be familiar with the Service Availability Forum's notions of Service Unit, Service Group, and administrative state. The Service Availability Forum's Application Interface Specification (available from http://www.saforum.org/) is a good place to start.

In brief, the sample applications in the Evaluation System are part of service units which in turn are part of service groups. Service groups (and the service units that make up the service groups) can be in "administrative" states which include "LockInstantiation", "LockAssignment", and "Unlocked". There are other states, but these are the ones we care about for the purposes of this Evaluation System. If the administrative state of a service unit is "LockInstantiation" then the application that is part of that service unit will not even be started. If the administrative state is "LockAssignment" then the application will be started, but it will not be assigned any work. If the administrative state is "Unlocked" then it will not only be started, but will have a workload assigned to it, which is to say that it will start doing work (or start providing service), rather than idly sit waiting for work.

The administrative state of a service unit or service group can change from LockInstantiation to LockAssignment, from LockAssignment to Unlocked, or back to LockInstantiation, from Unlocked to LockAssignment. A picture might help here:

Partial Service Group Administrative State Diagram

As the figure shows, the administrative state of a service unit (or service group) can change from "LockInstantiation" to "LockAssignment" and from there to "Unlocked", or back to "LockInstantiation". One way to change the administrative state of a service group is with the SAFplus Platform Console command line interface.

To use the SAFplus Platform Console:

1. Open a terminal on the Development Machine. (Or ssh into System Controller node as root, if you are running SAFplus Platform on a machine other than the development machine.)
2. Change to image bin directory:

   # cd /root/asp/bin

3. Start the SAFplus Platform Console

   # ./asp_console

4. From within the SAFplus Platform Console:

   cli[Test]-> setc 1
   cli[Test:SCNodeI0]-> setc cpm
   cli[Test:SCNodeI0:CPM]-> amsLockAssignment sg csa101SGI0
   

   The above changes the administrative state of the group csa101SGI0 from "locked-for-instantiation" to "locked-for-assignment".
   For the command cli[Test]-> setc 1, the 1 represents the physical slot number of the System Controller within the Chassis. Remember that we set our System Controller to be in slot 1 in the make images dialog.

5. Now lets tail the application log file so that we can see whats going on. In another window, as root, run:

   # tail -f /root/asp/var/log/csa101I0Log.latest
   

   You should see the following:

   /root/asp/var/log/csa101I0Log.latest

   Tue Jul 15 21:32:06 2008 (SCNodeI0.10849 : csa101_EO.---.---.00034 : INFO) Component [csa101I0] : PID [10849]. Initializing Tue Jul 15 21:32:06 2008 (SCNodeI0.10849 : csa101_EO.---.---.00035 : INFO) IOC Address  : 0x1 Tue Jul 15 21:32:06 2008 (SCNodeI0.10849 : csa101_EO.---.---.00036 : INFO) IOC Port  : 0x80 Tue Jul 15 21:32:06 2008 (SCNodeI0.10849 : csa101_EO.---.---.00037 : INFO) csa101: Instantiated as component instance csa101I0. Tue Jul 15 21:32:06 2008 (SCNodeI0.10849 : csa101_EO.---.---.00038 : INFO) csa101I0: Waiting for CSI assignment...

6. Next change the administrative state of the csa101SGI0 service group to "unlocked" by running (in the SAFplus Platform Console) :

   # cli[Test:SCNodeI0:CPM]-> amsUnlock sg csa101SGI0
   

   In the window where you're running the "tail -f" you should see:

   /root/asp/var/log/csa101I0Log.latest

   Tue Jul 15 21:36:17 2008 (SCNodeI0.10849 : csa101_EO.---.---.00049 : INFO) csa101: ACTIVE state requested; activating service Tue Jul 15 21:36:18 2008 (SCNodeI0.10849 : csa101_EO.---.---.00050 : INFO) csa101: Hello World! . Tue Jul 15 21:36:19 2008 (SCNodeI0.10849 : csa101_EO.---.---.00051 : INFO) csa101: Hello World! . Tue Jul 15 21:36:20 2008 (SCNodeI0.10849 : csa101_EO.---.---.00052 : INFO) csa101: Hello World! . Tue Jul 15 21:36:21 2008 (SCNodeI0.10849 : csa101_EO.---.---.00053 : INFO) csa101: Hello World! . Tue Jul 15 21:36:22 2008 (SCNodeI0.10849 : csa101_EO.---.---.00054 : INFO) csa101: Hello World! .

   As you can tell from the output log our component is up and running! It is continuously printing our 'Hello World!' output.

7. Now change the state of the csa101SGI0 service group back to "locked-for-assignment" by running (in the SAFplus Platform Console):

   # cli[Test:SCNodeI0:CPM]-> amsLockAssignment sg csa101SGI0
   

   In the tail -f output you should see:

   /root/asp/var/log/csa101I0Log.latest

   Tue Jul 15 21:39:29 2008 (SCNodeI0.10849 : csa101_EO.---.---.00241 : INFO) csa101: Hello World! . Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00242 : INFO) Component [csa101I0] : PID [10849]. CSI Set Received Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00243 : INFO) CSI Flags  : [Target One] Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00244 : INFO) CSI Name  : [csa101CSII0] Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00245 : INFO) HA State  : [Quiesced] Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00246 : INFO) csa101: Acknowledging new state Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00249 : INFO) Component [csa101I0] : PID [10849]. CSI Remove Received Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00250 : INFO) CSI  : csa101CSII0 Tue Jul 15 21:39:30 2008 (SCNodeI0.10849 : csa101_EO.---.---.00251 : INFO) CSI Flags  : 0x2

   Our component has been put into Lock Assignment state so our 'Hello World!' output has stopped printing to the log.

8. At this point you can either unlock the service group to change its state to "unlocked" or you can lock it for instantiation to change it to state "locked-for-instantiation". The latter will cause the csa101 process to die. From state "locked-for-assignment", it is possible to change the state to "locked-for-instantiation" by running (in the SAFplus Platform Console):

   cli[Test:SCNodeI0:CPM]-> amsLockInstantiation sg csa101SGI0
   cli[Test:SCNodeI0:CPM] -> end
   cli[Test:SCNodeI0] -> end
   cli[Test] -> bye
   

Stopping SAFplus Platform

To stop SAFplus Platform on the System Controller

1. Open a shell.
2. ssh into the System Controller node as root.
3. Once logged in, run the following command

   # cd /root/asp
   # etc/init.d/asp stop
   

Summary and Next Steps

In the csa101 example we learned the following.

• How to create a system model using the SAFplus Platform IDE.
• How to generate the source code.
• How to customize this source code to fit a specific application.
• How to configure and build the customized source code.
• How to make runtime images and deploy them to target machines.
• How to start and stop SAFplus.
• How to interact with system components using the SAFplus Platform Console.

The next logical step would be to run through the SAFplus Platform Evaluation System User Guide. This guide goes over more complex system configurations and introduces new concepts.

For more in depth information on the SAFplus Platform IDE see the SAFplus Platform IDE User Guide.

For more in depth information on the SAFplus Platform SDK see the SAFplus Platform SDK User Guide.

Appendix A: target.conf Settings

Below is a description of the values in the settings in the target.conf file.

1. TRAP_IP (Mandatory): Specifies where the SNMP SubAgent should send traps at runtime. If you do not have an SNMP SubAgent in your model specify 127.0.0.1 as the value. e.g.:

   TRAP_IP=127.0.0.1
   

2. CMM_IP (Mandatory if deployed on an ATCA chassis): Specifies the IP address of the target system's chassis management module or shelf manager. ATCA chassis Example:

   CMM_IP=169.254.1.2
   

3. CMM_USERNAME and CMM_PASSWORD (Mandatory if deployed on an ATCA chassis): Specifies the username and password required for the OpenClovis SAFplus Platform Chassis Manager to connect to the target system's chassis management module. e.g.:

   CMM_USERNAME=root
   CMM_PASSWORD=password
   

4. INSTALL_PREREQUISITES=YES|NO (Mandatory): Specifies whether the target images will include 3rd party runtime prerequisites or not. Say YES if the target nodes do not meet the target host requirements specified in the Installation section of this document. e.g.:

   INSTALL_PREREQUISITES=YES
   

5. INSTANTIATE_IMAGES=YES|NO (Mandatory): Specifies whether make images will generate node-instance specific images instead of only generating node-type specific images. This option is a development optimization for advanced users of SAFplus Platform SDK. If unsure, say YES. e.g.:

   INSTANTIATE_IMAGES=YES
   

6. CREATE_TARBALLS=YES|NO (Mandatory): Specifies whether the node-instance specific images created will be packaged into tarballs for deployment onto the target system. If unsure, say YES. e.g.:

   CREATE_TARBALLS=YES
   

7. TIPC_NETID (Mandatory): Specifies a unique identifier used by TIPC to set up interprocess communication across the deployed OpenClovis SAFplus Platform cluster. This is an unsigned 32-bit integer, and must be unique for every model that is deployed. e.g.:

   TIPC_NETID=1337
   

8. Node Instance Details: These specify the node-instance specific parameters required for deploying the model. For each node in the model there is a corresponding entry in the file:
   1. SLOT_<node instance name> (Mandatory): Specifies which slot the node is located in. The first slot is slot 1 -- DO NOT USE SLOT NUMBER 0, it is invalid. When deployed to an ATCA chassis, the physical slot in which the blade is actually installed will override this value. When deployed to regular (non-ATCA) systems, this is a logical slot and must be unique for every node in the cluster. e.g.:

      SLOT_SCNodeI0=1
      

   2. LINK_<node instance name> (Optional): Specifies the ethernet interface used by the node for OpenClovis SAFplus Platform communication with the rest of the cluster. If unspecified, this defaults to eth0. e.g.:

      LINK_SCNodeI0=eth0
      

   3. ARCH_<node instance name> (Optional if ARCH is specified): Specifies the target architecture of the node as a combination of machine architecture (MACH) and linux kernel version. This is only required on a per-node basis if the target cluster has heterogeneous architectures across the nodes. If it is a homogeneous cluster, a single ARCH parameter (described below) will suffice. e.g.:

      ARCH_SCNodeI0=i386/linux-2.6.14
      

   4. ARCH (Optional if node-specific ARCH_ parameters are specified): Specifies the target architecture of all nodes in a homogeneous cluster as a combination of machine architecture (MACH) and linux kernel version. Note: The build process automatically populates this variable based on the last target the model is built for.e.g.:

      ARCH=i386/linux-2.6.14
      

   For example, if we have a three-node cluster with the following details:

   Example Node Instance Detail

   Node Name	Slot Number	Link Interface	Architecture
   SCNodeI0	1	eth0	i386/linux-2.6.14
   PayloadNodeI0	3	eth0	i386/linux-2.6.14
   PayloadNodeI1	4	eth1	ppc/linux-2.6.9

   we would specify the node instance details as:

   SLOT_SCNodeI0=1
   SLOT_PayloadNodeI0=3
   SLOT_PayloadNodeI1=4
   
   LINK_SCNodeI0=eth0
   LINK_PayloadNodeI0=eth0
   LINK_PayloadNodeI1=eth1
   
   ARCH_SCNodeI0=i386/linux-2.6.14
   ARCH_PayloadNodeI0=i386/linux-2.6.14
   ARCH_PayloadNodeI1=ppc/linux-2.6.9
   

Appendix B: AMF Configuration Details

This appendix gives brief descriptions of configuration details for instances of different entities (like Node, Service Group, Service Unit etc) that are present in the Clovis -> AMF Configuration dialog box.

Node Instance

This screen displays the node instance that was created by the Node Instance Wizard. This node instance was created because the node type SCNode was selected on the wizard screen.

Node Instance Details

The information on this screen is described below.

• Node Instance Name: This field holds the name of the node instance. This name must be unique. The name that was generated combines the node type (SCNode), the letter I (for Instance), and the number 0 (since this is the first instance of this type).
• Node Type: This field holds the node type that was selected on the wizard screen.
• MOID: This is the unique identifier for the node instance. It was generated by the wizard. The format of this ID is a string representing the one and only instance of the chassis (\Chassis:0) defined in the Resource Editor followed by a string representing the first and only instance of the blade type (\SysBlade:0) that was selected in the Node Instance Wizard.
  MOID is an acronym for Managed Object Identifier. It must be unique and is used to identify which hardware chassis and blade type this instance will run on.

Service Unit Instance

This screen displays the service unit instance that was created by the Service Group Instance Wizard. This service unit instance was created because the service unit type is associated with both the selected node type (SCNode) and the selected service group type (csa101SG) in our model.

SU Instance Details

The information on this screen is described below.

• SU Instance Name: This field holds the name of the service unit instance. This name must be unique. The name that was generated combines the service unit type (csa101SU), the letter I (for Instance), and the number 0 (since this is the first instance of this type).
• Service Unit Type: This field holds the type of the service unit instance.

Component Instance

This screen displays the component instance that was created by the Service Group Instance Wizard. This component instance was created because the component type is associated with the created parent service unit type (csa101SU) in our model.

Component Instance Details

The information on this screen is described below.

• Component Instance Name: This field holds the name of the component instance. This name must be unique. The name that was generated combines the component type (csa101), the letter I (for Instance), and the number 0 (since this is the first instance of this type).
• Component Type: This field holds the type of the component instance.

Service Group Instance

This screen displays the service group instance that was created by the Service Group Instance Wizard. This service group instance was created because the service group type csa101SG was selected on the wizard screen.

Service Group Instance Details

The information on this screen is described below.

• SG Instance Name: This field holds the name of the service group instance. This name must be unique. The name that was generated combines the service group type (csa101SG), the letter I (for Instance), and the number 0 (since this is the first instance of this type).
• ServiceGroup Type: This field holds the type of the service group instance.
• Associated Service Units: This button is used to associate service unit instances with this service group instance. Creating this association indicates that the selected service unit(s) will run within this service group instance.

Clicking the Associated Service Units Edit... button will display the following dialog.

Associated Service Units Dialog

This dialog lists the service unit instances that can be associated with this service group instance. The list contains only one item, the service unit instance that was created by the wizard. This item is checked indicating that the wizard automatically chose this service unit instance to run within the service group instance.

Service Instance Instance

This screen displays the service instance that was created by the Service Group Instance Wizard. This service instance was created because the service instance type is associated with the parent service group type (csa101SG) in our model.

Service Instance Details

The information on this screen is described below.

• Service Instance Name: This field holds the name of the service instance. This name must be unique. The name that was generated combines the service instance type (csa101SI), the letter I (for Instance), and the number 0 (since this is the first instance of this type).
• ServiceInstance Type: This field holds the type of the service instance.

Component Service Instance Instance

This screen displays the component service instance that was created by the Service Group Instance Wizard. This component service instance was created because the component service instance is associated with the parent service instance type (csa101SI) in our model.

Component Service Instance Details

The information on this screen is described below.

• Component Service Instance Name: This field holds the name of the component service instance. This name must be unique. The name that was generated combines the component service instance type (csa101CSI), the letter I (for Instance), and the number 0 (since this is the first instance of this type).
• ComponentServiceInstance Type: This field holds the type of the component service instance.