-
Notifications
You must be signed in to change notification settings - Fork 133
The Structure of a CSD
A CSD is packaged and distributed as a jar file. The jar is self-contained and encases all the description and logic needed to manage the service type in CM.
The following files and directories are treated specially when read by the CSD framework:
descriptor/service.sdldescriptor/service.mdlscripts/aux/
At the heart of the CSD is the service descriptor language (SDL) file: descriptor/service.sdl. This is a json file that describes how to manage a service type with the same name as the CSD. This file includes:
- the service types and associated role types
- how to start the service/roles
- parameters for both the service and role types
- additional commands
- configuration file generators
The service.sdl file must be located in the descriptor directory. See the Service Descriptor Language Reference for more details.
Service monitoring behavior may be specified in an optional service monitoring descriptor language (MDL) file: descriptor/service.mdl. This is a json file that describes how Cloudera Manager should behave when monitoring a service type with the same name as the CSD. This file includes:
- new monitored entity types
- new metrics for the service, roles and monitored entity types.
The service.mdl file is an optional part of a CSD, but it must be located in the descriptor directory if one is specified. See the Service Monitoring Descriptor Language Reference for more details.
This directory contains all the executable scripts that are used to control the underlying service. These scripts are referenced by the service.sdl file through script runners. Scripts can be written in any language that can be executed on the cluster. Bash is often used since it is ubiquitous on Linux distributions. All files in this directory are sent to the CM agent along with all generated configuration files, and written to the agent's process directory.
See Control Scripts for more details.
A CSD can optionally have an aux directory. Auxiliary files can exist in this directory and, if they do, are also sent down to the agent along with the scripts directory. This can be useful if there are static configuration files, like topology.py, that are needed by the service and are not generated by the CSD. Oftentimes substitution variables are added to these static configuration files and then replaced by the control scripts.
The name of the CSD jar must conform to the following format: <name>-<csd-version>-<extra>.jar. For example, a release build of version 1.0 of the Spark CSD is: SPARK-1.0.jar. The <extra> section of the file name is reserved for snapshot builds of the CSD when building with maven. So for example, a snapshot build of the Spark CSD would be: SPARK-1.0-SNAPSHOT.jar. The <extra> is ignored by Cloudera Manager.
Note: csd-version used here is NOT directly related to the underlying software version. For example SPARK-1.0.jar, the Spark CSD version 1.0, might control a Spark 0.9 software.