Active System Manager Release 8.2 SDK Reference Guide

{
                                 "name": "my_module",
                                 "version": "0.1.0",
                                 "operatingSystemSupport": [
                                 {
                                 "operatingSystem": "RedHat",
                                 "releaseVersions": [ "5", "6", "7" ]
                                 },
                                 ],
                                 "requirements": [
                                 {
                                 "name": "pe",
                                 "versionRequirement": ">= 3.0.0 & 2015.3.0"
                                 },
                                 {
                                 "name": "puppet",
                                 "versionRequirement": ">= 3.0.0 & 5.0.0"
                                 }
                                 ],
                                 "classes": [ ... ],
                                 "types": [ ... ]
                                 }
                                 
                              

This is almost a direct copy of a Puppet metadata.json file, except for renaming of some keys. A simple script to generate this structure from a Puppet module can be downloaded from the Dell techcenter at: http://en.community.dell.com/techcenter/converged-infrastructure/w/wiki/4318.dell-active-system-manager.

                                    'operatingsystem_support' => 'operatingSystemSupport'
                                    'operatingsystem'         => 'operatingSystem'
                                    'operatingsystemrelease'  => 'releaseVersions'
                                    'version_requirement'     => 'versionRequirement'
                                    'requirements'            => 'requirements'
                                    'version_range'           => 'versionRequirement'
                                 

The `name`, `version`, `operatingSystemSupport` and `requirements` fields are semantically identical to the fields of the analogous names contained in the `metadata.json` file.

An explanation of each field is as follows.

• name: The name of the module. By convention puppet module names are generally of the form <maintainer>-<module>. For example, the name of the Puppet Labs PostgreSQL module is ‘puppetlabs-postgresql’. If present, the <maintainer> portion is removed to determine the module directory name that the module is copied into. For example, the puppetlabs-postgresql module would be copied into a directory called postgresql in the ASM appliance modules directory.
• version: The version of the module. Currently ASM only allows one version of a module to be uploaded at a time.
• operatingSystemSupport: A list of hashes containing `operatingSystem` and `releaseVersions`. This describes the operating systems and versions that are supported by the module. See the Puppet documentation for more detail.
• requirements: A list of hashes containing name and versionrequirements of the puppet the module is to function with. The `name` "pe" refers to supported Puppet Enterprise versions and the name "puppet" refers to open-source puppet. If these are present ASM validates that the module is supported by the version of Puppet that ASM ships with. That is Puppet Enterprise 3.3 which is roughly equivalent to open-source Puppet version 3.6.
  • NOTE: Because of the semantic version of library used, the puppet intersection expression, >=3.4.0<5.0.0, should be expressed differently as, >=3.4.0 & 5.0.0.
• classes: A list of Puppet classes that the Application Module wants to instantiate and expose through the ASM UI. The format is discussed in more detail following. Classes in Puppet are singletons, so only one instance of any class component can be attached to a given ASM server or VM component.
• types: A list of Puppet resources that the Application Module wants to instantiate and expose through the ASM UI. The data format for `types` is identical to the `classes`. Unlike classes, types are not singletons and more than one "type" component could be attached to the same ASM server or VM component.

The contents of the classes and types arrays are explained next.