- API >
- Public API Resources >
- Automation Configuration
Automation Configuration¶
On this page
Overview¶
The Public API provides the automationConfig
endpoint to let you
manipulate a group’s automation configuration. The processes you specify in the
configuration, define the deployment that your
Automation Agents will
attempt to build. These processes can include clusters, replica sets and standalones,
as well as Backup and Monitoring Agents.
Each Automation Agent resides on its own host and is responsible for the processes the configuration defines for that host. The agent runs the processes as defined by the configuration. When a running process matches its defined configuration, the process is in “goal state.” When all processes on all hosts are in goal state, the deployment itself is in goal state.
Operations¶
GET /api/public/v1.0/groups/GROUP-ID/automationConfig
Retrieve the current automation configuration for a group.
PUT /api/public/v1.0/groups/GROUP-ID/automationConfig
Update a group’s automation configuration. For steps for updating an automation configuration, see Deploy a Cluster through the API.
Updates¶
To update the configuration through the automationConfig
endpoint,
send an object that contains a specific subset of the
configuration’s fields. This is
the same subset as you receive when you retrieve the configuration through
the endpoint.
When you submit updates, Ops Manager makes internal modifications to the data and then saves your new configuration version. For example, Ops Manager might add a field to each specified community MongoDB version to indicate where the agents download them from.
The Automation Agents continuously poll Ops Manager for changes to the configuration and fetch configuration updates when they occur. The agents then adjust the states of their live processes to match. For a tutorial on updating a deployment using the API, see Deploy a Cluster through the API.
Concurrent Modifications Warning¶
There is no protection in the Public API to prevent concurrent modifications. If two administrators both start with a configuration based on the current version, make their own modifications, and then submit their modifications, the later modification wins.
Other Representations of the Automation Configuration¶
You can view the internal representation of the configuration through the Raw AutomationConfig page on the Deployment tab of the Ops Manager interface. The raw configuration shows the internal representation of the configuration that Ops Manager stores, including fields that should not be updated through the API.
The Automation Agent also stores a copy of the configuration in the
mms-cluster-config-backup.json
file. The agent stores the most recent
version of configuration with which the agent was able to reach goal
state. If an agent is not able to process configuration changes, it
continues to store an older version of the configuration.
Sample Automation Configuration Entity¶
Entity Fields¶
Name | Type | Description |
---|---|---|
monitoringVersions | array | Optional. Objects that define version information for each Monitoring Agent. |
- hostname | string | The hostname of the machine that runs the Monitoring Agent. If the Monitoring Agent is not running on the machine, Ops Manager installs it. |
- logPath | string | Optional. The directory where the agent stores its logs. The
default is to store logs in /dev/null . |
- logRotate | object | Optional. Enables log rotation for the MongoDB logs for a process. |
- - sizeThresholdMB | number (integer or float) | The maximum size in MB for an individual log file before rotation. |
- - timeThresholdHrs | integer | The maximum time in hours for an individual log file before rotation. |
backupVersions | array | Optional. Objects that define version information for each Backup Agent. |
- hostname | string | The hostname of the machine that runs the Backup Agent. If the Backup Agent is not running on the machine, Ops Manager installs it. |
- logPath | string | Optional. The directory where the agent stores its logs. The
default is to store logs in /dev/null . |
- logRotate | object | Optional. Enables log rotation for the MongoDB logs for a process. |
- - sizeThresholdMB | number (integer or float) | The maximum size in MB for an individual log file before rotation. |
- - timeThresholdHrs | integer | The maximum time in hours for an individual log file before rotation. |
processes | array | The processes array contains objects that define the
mongos and mongod instances that Ops Manager
manages. Each object defines a different instance. |
- name | string | A unique name to identify the instance. |
- processType | string | Either mongod or mongos . |
- version | string | The name of the mongoDbVersions specification used with
this instance. |
- hostname | string | Optional. The name of the host this process should run on. This
defaults to localhost . |
- cluster | string | Optional. Required for a mongos. The name of the
cluster. This must correspond to the sharding.name field
in the sharding array for the mongos. |
- logRotate | object | Optional. Enables log rotation for the MongoDB logs for a process. |
- - sizeThresholdMB | number (integer or float) | The maximum size in MB for an individual log file before rotation. |
- - timeThresholdHrs | integer | The maximum time in hours for an individual log file before rotation. |
- authSchemaVersion | integer | Required if auth is turned on. Otherwise optional. The schema
version of the user credential documents. This should match all
other elements of the processes array that belong to the same
cluster. The possible values are 1 , 3 , and 5 . The
default is 3 for 2.6 clusters and 1 for 2.4
clusters. |
- <args> | object | This field is named either args2_6 , for MongoDB versions 2.6
and higher (including 3.0 and higher), or args2_4 , for versions
2.4 and earlier. The field contains a MongoDB configuration
document in the format appropriate to the version. For information
on format and supported MongoDB options, see supported
configuration options. |
replicaSets | array | Optional. Objects that define the configuration of each
replica set. The Automation Agent uses the values in this
array to create valid replica set configuration documents. The agent regularly checks
that replica sets are configured correctly. If a problem occurs,
the agent reconfigures the replica set according to its
configuration document. The array can contain the following fields
from a replica set configuration document: _id ; version ;
and members . The members.host field must specify the host’s
name as listed in processes.name . The Automation Agent expands
the host field to create a valid replica set configuration. |
sharding | array | Optional. Objects that define the configuration of each sharded cluster. Each object in the array contains the specifications for one cluster. The Automation Agent regularly checks each cluster’s state against the specifications. If the specification and cluster don’t match, the agent will change the configuration of the cluster, which might cause the balancer to migrate chunks. |
- name | string | The name of the cluster. This must correspond with the value in
processes.cluster for a mongos. |
- configServer | array | String values that provide the names of each config server’s hosts. The host names are the same names as are
used in each host’s processes.name field. |
- shards | array | Objects that define the cluster’s shards. |
- - _id | string | The name of the shard. |
- - rs | string | The name of the shard’s replica set, as specified in the
replicaSets._id field. |
- collections | array | Objects that define the sharded collections and their shard keys. |
mongoDbVersions | array | The mongoDbVersions array is required and defines versions of
MongoDB used by the MongoDB instances. |
- name | string | The MongoDB version. |
Examples¶
For configuration examples, please see the following page on GitHub: https://github.com/10gen-labs/mms-api-examples/tree/master/automation/.