Save the sample SDK project zip file on your file system.
File > Import.
Import dialog box, choose
General > Existing Projects into
root directory and browse to the location where you extracted the
The project is
Using EGit to Import
the Open Automation SDK Bundle
Git with Eclipse (EGit) is an Eclipse plug-in that enables using the distributed version control system Git. EGit uses a connector plug-in in Eclipse to import the Open Automation SDK bundle into the IDE.
The Eclipse IDE downloaded from the www.Eclipse.org site contains support for Git in its default configuration. If the Git functionality is missing in your Eclipse IDE installation, you can use the Eclipse installation manager to install it. See the following:
When you develop a module to support new devices, follow these guidelines:
Develop for a device family so that you have only one module to support all devices in the family.
Develop a single module to support only devices within the same category. A module should handle only compute devices, network devices, or storage devices. For example, do not develop a module that supports both a network switch and a storage controller. Instead, develop one module for the network switch and one module for the storage controller.
Ensure that the devices supported by the same module are similar.
The same device may come in different models that are meant for distinct purposes. In such cases, it may be appropriate to use different modules to support them.
The following items must be in place for your custom module to work:
A class extending AbstractCloupiaModule.
Override the OnStart method in the Module Class that extends the AbstractCloupiaModule.
A .feature file specifying your dependent jars and module class.
A module.properties file is required in the custom module.
Before You Begin
Refer to FooModule in the sample project of the Open Automation SDK bundle.
Extend the AbstractCloupiaModule class and register all your custom components in this class.
.feature file that specifies the dependent jars and
This file must
end with an extension of
.feature; see foo.feature for reference. The best
practice is to name this file with your module ID. For more details about the
.feature file, see
Packaging the Module.
necessary custom jar files to the
properties file at the root level of your module jar.
Cisco UCS Director
provides you with a
properties file for validation purposes. The SDK
sample provides you with a build file that handles the packaging process.
The contents are
described in the following table:
Table 1 New
The unique identifier for the module. This property is mandatory.
We recommend that you restrict this ID to a string of 3 to 5 lowercase alphabetic ASCII characters.
The current version of your module. This property is mandatory.
The version of Cisco UCS Director designed to support your module (with which your module works best). This property is mandatory.
The path (/location) where all your tasks must be placed. This property is mandatory.
The category parameter is the full path to the location where your tasks are placed. If the tasks module is not validated, the path is set to Open Automation Community Tasks/Experimental. If the tasks module is validated, the tasks are placed relative to the root folder. For example, you can use /Physical Storage Tasks/foo, /Open Automation Community Tasks/Validated/foo, or /foo. In the last case, there is a folder at root level called foo. This feature enables developers to place tasks in categories that are not under Open Automation or in its categories.
The version of the format of this module. This property is mandatory. By default, 1.0 version is set for the custom module.
1.0 is the only acceptable value here.
A user-friendly string that identifies your module in the Open Automation reports.
A user-friendly description of what your module does.
description=UCSD Open Automation Sample Module
An email address that consumers of your module can use to request support.
An encrypted key that the Cisco UCS Director Open Automation group provides for validating the module.
Modifying any mandatory properties invalidates your module. If you change any of the mandatory properties, you must request validation again. The name, description, and contact values, which are not mandatory, can be modified or omitted without revalidation.
A module is packaged with all the necessary classes, dependent JAR files, a module.properties file, and a .feature (pronounced "dot-feature") file. The .feature file is placed in the same folder as the root of the project. The .feature file shows the JAR associated with this module and the path to the dependent JAR files. The name of the .feature file is <moduleID>-module.feature.
example shows the content of a
We recommend that you use the Apache ANT build tool that comes with Eclipse. You can use any build tool or create the build by hand, but you must deliver a package with the same characteristics as one built with ANT.
1.If your module depends on JARs that are not provided with the sample source code, include the jars in the build.xml file so that they are packaged in the zip file.
2.From the build.xml file, run the ANT target build.
Command or Action
If your module depends on JARs that are not provided with the sample source code, include the jars in the build.xml file so that they are packaged in the zip file.
The following example shows a module layout with a third-party JAR:
The module jar and .feature are at the top level of the zip file. We recommend that you put the third-party jars under the /moduleID/lib folder path, then any other sub-directories you may want to add.
When you list the jars in the .feature file, ensure that the jars start with features/; this is mandatory. This convention enables you to include the path to the jar. The path of each jar must be the same path that is used in your zip file. We recommend that you put your module jar first, followed by its dependencies, to ensure that your module loads.
From the build.xml file, run the ANT target build.
The zip file is generated and saved to the base directory of your project. (We recommend that you create your own project directory for your module. For convenience, in this example we assume that the sample project is the base directory for your project.)
Deploying a Module on Cisco UCS Director
The Cisco UCS Director user interface provides Open Automation controls that you can use to upload and manage modules. Use these controls to upload the zip file of the module to Cisco UCS Director.
Only zip-formatted files can be uploaded using the Open Automation controls.
Before You Begin
Acquire shell administrator access on the Cisco UCS Director VM. You can get this access from your system administrator. To use the Cisco UCS Director Shell Menu as a shell administrator, use SSH to access Cisco UCS Director, using the login shelladmin with the password that you got from the administrator.
For SSH access in a Windows system, use PuTTY (see http://www.putty.org/). On a Mac, use the built-in terminal application's SSH utility.
Administration > Open
Automation page, click
The Modules page displays the following columns:
The ID of the module.
The name of the module.
The description of the module.
The current version of the module. The module developer must determine how to administer versioning of the module.
Which version of Cisco UCS Director best supports this module.
The contact information of the person responsible for technical support for the module.
The time at which the module was uploaded.
The status of the module. Possible statuses are: Enabled, Disabled, Active, and Inactive.
You can control whether a module is enabled or disabled. If enabled, Cisco UCS Director attempts to initialize the module; if disabled, Cisco UCS Director ignores the module. A module is set to the Active state only when Cisco UCS Director is able to successfully initialize the module without throwing an exception.
Active does not necessarily mean that everything in the module is working properly; it merely indicates that the module is up. Inactive means that when Cisco UCS Director tried to initialize the module, a severe error prevented it from doing so. Typical causes for the Inactive flag are: the module is compiled with the wrong version of Java, or a class is missing from the module.
Indicates whether the module is validated or not.
To enable module activation on upload, ensure that the .feature file in your module is named after your module ID. For example: If moduleId is myFeatureName, then name your feature file myFeatureName.feature.
The Cisco UCS Director framework identifies and loads the .feature file by name, based on the module ID. If the name of the .feature file and the module ID are different, the .feature file does not load and the module is not activated. If you choose to give the module ID and the .feature file different names, you must restart Cisco UCS Director to activate the module.
Click Add to add a new module.
The Add Modules dialog box appears.
Choose the module zip file from your local files and click Upload to upload the module zip file.
Enable the module by choosing the module in the Modules table and clicking Enable.
Wait while Cisco UCS Director activates the module.
Restarting Cisco UCS Director is not required to enable a module. However, you must restart Cisco UCS Director to disable, modify, or delete a module.
What to Do Next
Once the module is active, you can test the module.