A basic example
of asm_input.json with the fields, classes, and types. A detailed
explanation of this follows in the next subsection.
{
"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.
The mapping from Puppet manifest keys to ASM
module keys is:
'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.