Add documentation for /v1/config/stages 'activate' parameter

This commit is contained in:
Chris Boot 2019-09-24 17:27:45 +01:00
parent aece8d61e2
commit fe6fdf57ba
1 changed files with 10 additions and 2 deletions

View File

@ -1848,8 +1848,12 @@ in the Director's deployment log.
Send a `POST` request to the URL endpoint `/v1/config/stages` and add the name of an existing
configuration package to the URL path (e.g. `example-cmdb`).
The request body must contain the `files` attribute with the value being
a dictionary of file targets and their content. You can also specify an optional `reload` attribute
that will tell icinga2 to reload after stage config validation. By default this is set to `true`.
a dictionary of file targets and their content.
Optional attributes include `reload` (defaults to `true`) and `activate` (defaults to `true`).
The `reload` attribute will tell icinga2 to reload after stage config validation.
The `activate` attribute will tell icinga2 to activate the stage if it validates.
If `activate` is set to `false`, `reload` must also be `false`.
The file path requires one of these two directories inside its path:
@ -1899,6 +1903,10 @@ can be disabled by setting `reload` to `false` in the request.
If the validation for the new config stage failed, the old stage
and its configuration objects will remain active.
Activation may be inhibited even for stages that validate correctly by setting
`activate` to `false`. This may be useful for validating the contents of a stage
without making it active, for example in a CI (continuous integration) system.
> **Note**
>
> Old stages are not purged automatically. You can [remove stages](12-icinga2-api.md#icinga2-api-config-management-delete-config-stage) that are no longer in use.