Configuration file definitions

Definitions describe config files that LCM needs to generate configs for the target nodes. The LCM UI uses these to generate UI dialogs, but an API consumer can use them to know what the valid properties are for each config file. As with most of the LCM API, definitions are discoverable. The running API can be navigated by going to /api/v2/lcm/definitions/.

GET /api/v2/lcm/definitions/

Gets a list of all of the DSE versions supported by OpsCenter and LCM, with links to the definitions for each version.

Example:

curl http://localhost:8888/api/v2/lcm/definitions/

Output:

{
    "dse": [
        {
            "version": "4.7.0",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.0/"
        },
        {
            "version": "4.7.1",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.1/"
        },
        {
            "version": "4.7.2",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.2/"
        },
        {
            "version": "4.7.3",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.3/"
        },
        {
            "version": "4.7.4",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.4/"
        },
        {
            "version": "4.7.5",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.5/"
        },
        {
            "version": "4.7.6",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.6/"
        },
        {
            "version": "4.7.7",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.7/"
        },
        {
            "version": "4.7.8",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.7.8/"
        },
        {
            "version": "4.8.0",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.0/"
        },
        {
            "version": "4.8.1",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.1/"
        },
        {
            "version": "4.8.2",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.2/"
        },
        {
            "version": "4.8.3",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.3/"
        },
        {
            "version": "4.8.4",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.4/"
        },
        {
            "version": "4.8.5",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.5/"
        },
        {
            "version": "4.8.6",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.6/"
        },
        {
            "version": "4.8.7",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.7/"
        },
        {
            "version": "4.8.8",
            "href": "http://localhost:8888/api/v2/lcm/definitions/4.8.8/"
        },
        {
            "version": "5.0.0",
            "href": "http://localhost:8888/api/v2/lcm/definitions/5.0.0/"
        }
    ]

}

GET /api/v2/lcm/definitions/{version}/

Gets the definitions for a specific version of DSE.

At the top level are file-id keys. These loosely look like the filename, when there is an actual distinctive filename. Example: cassandra-yaml for /etc/dse/cassandra/cassandra.yaml.

There are a number of properties you may notice missing from cassandra-yaml - these are node-specific properties like listen_address and native_transport_address*, and should be configured using the fields on Node.

The value for each definitions key is an object with the following attributes:

renderer: Used internally by LCM to generate the output for the config file.
display-name: Used by LCM UI.
groupings: Used by LCM UI.
properties: Each key represents the name of a config file property. Some properties are simple scalar values, but they can also be nested objects or lists. See Property Fields below for more information.

Example:

curl http://localhost:8888/api/v2/lcm/definitions/4.8.6/

Output:

Go to the actual endpoint on your OpsCenter machine in a browser (we recommend using a JSON viewer plugin for easy reading). A single definitions response can be rather large, and is subject to change during operation when OpsCenter automatically downloads updated definitions.

Property fields

When using definitions as a reference for building a config-profile it is important to understand the different types of properties, and how they translate into a config structure. Note that much of the property metadata is related to the LCM UI. This topic covers only the attributes that are important for generating properly formed config profiles.

If a field has a default_value, that value is rendered in the config file by LCM automatically. You do not need to include such values in your config profile unless you intend to override the default.

Scalar types

Scalar types include primitive values such as integers, floating-point numbers, strings, and booleans. These are represented in the typical JSON format for these types.

Scalar types can be standalone top-level properties and sub-properties of more complex types (dict, list, and user_defined).

Example profile with scalar type properties:

{
    "datastax-version":"5.0.0",
    "name":"dev",
    "comment":"development profile",
    "json":{
        "cassandra-yaml":{
            "int_property": 14,
            "float_property": 0.1,
            "string_property": "value",
            "boolean_property": true
        }
    }
}

Dict type

Nested properties are defined as property type dict. In this case the value is a JSON object. All dict type properties have a fields attribute defining the object keys and what types are their values.

Example property definition:

{
    "request_scheduler_options": {

        "conditional": [
            {
                "eq": "org.apache.cassandra.scheduler.RoundRobinScheduler"
            }
        ],
        "depends": "request_scheduler",
        "type": "dict",
        "required": false,
        "fields": {
            "default_weight": {
                "default_value": 5,
                "type": "int",
                "required": true
            },
            "throttle_limit": {
                "default_value": 80,
                "type": "int",
                "required": true,
                "unit": "requests"
            }
        }
    }
}

When used in a config profile, the dict type property is represented as a nested JSON object with the corresponding keys:

{
    "datastax-version":"5.0.0",
    "name":"dev",
    "comment":"development profile",
    "json":{
        "cassandra-yaml":{
            "request_scheduler_options":{
                "default_weight":6,
                "throttle_limit": 90
            }
        }
    }
}

List type

Some config file property values are lists. A list type definition has a value_type attribute, indicating the type of the values in the list. The value_type can be any of the valid property types defined in this document.

Example property definition:

{
    "data_file_directories": {
        "value_type": "string",
        "default_value": [
            "/var/lib/cassandra/data"
        ],
        "type": "list",
        "required": true
    }
}

Example profile with list type property:

{
    "datastax-version":"5.0.0",
    "name":"dev",
    "comment":"development profile",
    "json":{
        "cassandra-yaml":{
             "data_file_directories": ["/mnt/data1","/mnt/data2"]
        }
    }
}

User-defined type

A user_defined type is almost the same as a dict type (the value is an object), but the keys are defined by the user.

The following example defines a user-defined type property for request scheduler options:

{
    "request_scheduler_options": {
        "conditional": [
            {
                "eq": "org.apache.cassandra.scheduler.RoundRobinScheduler"
            }
        ],
        "depends": "request_scheduler",
        "type": "dict",
        "required": false,
        "fields": {
            "weights": {
                "value_type": "int",
                "type": "user_defined",
                "required": false,
                "key_name": "keyspace"
            }
        }
    }
}

Example profile with user-defined type property:

{
    "datastax-version":"5.0.0",
    "name":"dev",
    "comment":"development profile",
    "json":{
        "cassandra-yaml":{
            "request_scheduler_options":{
                "keyspace_1": 1,
                "keyspace_2": 2
            }
        }
    }
}

Configuration file definitions

GET /api/v2/lcm/definitions/

GET /api/v2/lcm/definitions/{version}/

Property fields

Was this helpful?

Give Feedback