Skip to content

Commit

Permalink
Merge pull request #919 from HubSpot/config_docs
Browse files Browse the repository at this point in the history
update config docs for recently added fields
  • Loading branch information
ssalinas committed Feb 23, 2016
2 parents a9d74b8 + 413f1d4 commit 2cdee1d
Showing 1 changed file with 16 additions and 3 deletions.
19 changes: 16 additions & 3 deletions Docs/reference/configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,13 +52,19 @@ These are settings that are more likely to be altered.
| considerTaskHealthyAfterRunningForSeconds | 5 | Tasks which make it to TASK_RUNNING and run for at least this long (that are not health-checked) are considered healthy | long |
| healthcheckIntervalSeconds | 5 | Default amount of time to wait in between attempting task healthchecks | long |
| healthcheckTimeoutSeconds | 5 | Default amount of time to wait for healthchecks to return before considering them failed | long |
| killAfterTasksDoNotRunDefaultSeconds | 600 (10 minutes) | Amount of time after which new tasks (that are not part of a deploy) will be killed if they do not enter TASK_RUNNING | long |
| killAfterTasksDoNotRunDefaultSeconds | 600 (10 minutes) | Amount of time after which new tasks (that are not part of a deploy) will be killed if they do not enter TASK_RUNNING | long |
| healthcheckMaxRetries | | Default max number of time to retry a failed healthcheck for a task before considering the task to be unhealthy | int |
| healthcheckMaxTotalTimeoutSeconds | | Default total time to wait for healthchecks to pass | int |

#### Deploys ####
| defaultDeployStepWaitTimeMs | 0 | If using an incremental deploy, wait this long between deploy steps if not specified in the deploy | int |
| defaultDeployMaxTaskRetries | 0 | Allow this many tasks to fail and be retried before failing a new deploy | int |

#### Limits ####
| Parameter | Default | Description | Type |
|-----------|---------|-------------|------|
| maxDeployIdSize | 50 | Deploy ids over this size will cause deploy requests to fail with 400 | int |
| maxRequestIdSize | 100 | Request ids over this size will cause new requests to fail with 400 | int |
| maxRequestIdSize | 100 | Request ids over this size will cause new requests to fail with 400 | int |

#### Cooldown ####
| Parameter | Default | Description | Type |
Expand All @@ -74,6 +80,7 @@ These are settings that are more likely to be altered.
| loadBalancerQueryParams | null | Additional query parameters to pass to the Load Balancer API | Map<String, String> |
| loadBalancerRequestTimeoutMillis | 2000 | The timeout for making API calls to the Load Balancer API (these will be retried) | long |
| loadBalancerUri | null | The URI of the Load Balancer API (Baragon) | string |
| deleteRemovedRequestsFromLoadBalancer | false | If a request is removed from Singularity, issue a `DELETE` to the load balancer for that service | boolean |

#### User Interface ####
| Parameter | Default | Description | Type |
Expand All @@ -96,6 +103,7 @@ These settings are less likely to be changed, but were included in the configura
| persistHistoryEverySeconds | 3600 (1 hour) | Moves stale historical task data from ZooKeeper into MySQL, setting to 0 will disable history persistence | long |
| saveStateEverySeconds | 60 | State about this Singularity instance is saved (available over API) on this interval | long |
| checkScheduledJobsEveryMillis | 600000 (10 mins) | Check for new scheduled jobs and those running into the next scheduled time on this interval | long |
| checkExpiringUserActionEveryMillis | 45000 | Check for expiring actions that should be expired on this interval | long |

#### Mesos ####
| Parameter | Default | Description | Type |
Expand Down Expand Up @@ -129,11 +137,14 @@ These settings are less likely to be changed, but were included in the configura
| maxRequestsWithHistoryInZkWhenNoDatabase | infinite (disabled) | Delete history of oldest requests from zk when there are more than this number of requests, if we're not already persisting them to a database | int |
| deleteTasksFromZkWhenNoDatabaseAfterHours | 168 (7 days) | Delete old tasks from zk after this amount of time if we are not using a database | long |
| maxStaleTasksPerRequestInZkWhenNoDatabase | infinite (disabled) | Delete oldest tasks from zk when there are more than this number for a given request, if we're not already persisting them to a database | int |
| taskPersistAfterStartupBufferMillis | 60000ms (1 min) | Wait this long after a task starts before persisting it in history | long |
| deleteDeadSlavesAfterHours | 168 (7 days) | Remove dead slaves from the list after this amount of time | long |
| deleteUndeliverableWebhooksAfterHours | 168 (7 days) | Delete (and stop retrying) failed webhooks after this amount of time | long |
| waitForListeners | true | If true, the event system waits for all listeners having processed an event. | boolean |
| warnIfScheduledJobIsRunningForAtLeastMillis | 86400000 (1 day) | Warn if a scheduled job has been running for this long | long |
| warnIfScheduledJobIsRunningPastNextRunPct | 200 | Warn if a scheduled job has run this much past its next scheduled run time (e.g. 200 => ran through next two run times) | int |
| pendingDeployHoldTaskDuringDecommissionMillis | 600000ms (10 minutes) | Don't kill tasks on a decommissioning slave that are part of a pending deploy for this amount of time to allow the deploy to complete | long |
| defaultBounceExpirationMinutes | 60 | Expire a bounce after this many minutes if an expiration is not provided in the request to bounce | int |

## Mesos Configuration ##

Expand All @@ -147,7 +158,8 @@ These settings should live under the "mesos" field inside the root configuration
| frameworkId | null | | string |
| frameworkFailoverTimeout | 0.0 | | double |
| checkpoint | true | | boolean |

| credentialPrincipal | | Enable framework auth by setting both this and credentialSecret | String |
| credentialSecret | | Enable framework auth by setting both this and credentialPrincipal | String |

#### Resource Limits ####
| Parameter | Default | Description | Type |
Expand Down Expand Up @@ -205,6 +217,7 @@ These settings live under the "s3" field in the root configuration. If using the
| s3KeyFormat | | Search for logs with keys in this format, should be the same as the key format set in the SingularityS3Uploader | String |
| s3AccessKey | | aws access key for the specified s3 bucket | String |
| s3SecretKey | | aws secret key for the specified s3 bucket | String |
| missingTaskDefaultS3SearchPeriodMillis | 259200000ms (3 days) | Search over this many days for s3 logs when no task data is found | long |

## Sentry ##

Expand Down

0 comments on commit 2cdee1d

Please # to comment.