diff --git a/.markdownlint.json b/.markdownlint.json index 62ff374f..31dead19 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -1,7 +1,9 @@ { "default": true, "MD013": { - "line_length": "120" + "line_length": "120", + "code_blocks": false, + "tables": false }, "MD024": { "siblings_only": true diff --git a/dev/README.md b/dev/README.md index 82aa0567..212bb727 100644 --- a/dev/README.md +++ b/dev/README.md @@ -269,26 +269,18 @@ ERROR: Failed building wheel for cryptography **Solution:** - - ```bash LDFLAGS="-L$(brew --prefix openssl@1.1)/lib" CFLAGS="-I$(brew --prefix openssl@1.1)/include" pip install `cat engine/requirements.txt | grep cryptography` ``` - - ### django.db.utils.OperationalError: (1366, "Incorrect string value") **Problem:** - - ```bash django.db.utils.OperationalError: (1366, "Incorrect string value: '\\xF0\\x9F\\x98\\x8A\\xF0\\x9F...' for column 'cached_name' at row 1") ``` - - **Solution:** Recreate the database with the correct encoding. @@ -321,15 +313,11 @@ $ CDPATH="" make init When running `make init start`: - - ```bash Error response from daemon: open /var/lib/docker/overlay2/ac57b871108ee1b98ff4455e36d2175eae90cbc7d4c9a54608c0b45cfb7c6da5/committed: is a directory make: *** [start] Error 1 ``` - - **Solution:** clear everything in docker by resetting or: @@ -376,8 +364,6 @@ See solution for "Encountered error while trying to install package - grpcio" [h This problem seems to occur when running the Celery process, outside of `docker-compose` (via `make run-backend-celery`), and using a `conda` virtual environment. - - ```bash conda create --name oncall-dev python=3.9.13 conda activate oncall-dev @@ -396,8 +382,6 @@ File "~/oncall/engine/engine/__init__.py", line 5, in ImportError: dlopen(/opt/homebrew/Caskroom/miniconda/base/envs/oncall-dev/lib/python3.9/site-packages/grpc/_cython/cygrpc.cpython-39-darwin.so, 0x0002): symbol not found in flat namespace '_EVP_DigestSignUpdate' ``` - - **Solution:** [This solution](https://github.com/grpc/grpc/issues/15510#issuecomment-392012594) posted in a GitHub issue thread for diff --git a/docs/sources/oncall-api-reference/alertgroups.md b/docs/sources/oncall-api-reference/alertgroups.md index f0d68157..9dfe58e4 100644 --- a/docs/sources/oncall-api-reference/alertgroups.md +++ b/docs/sources/oncall-api-reference/alertgroups.md @@ -63,14 +63,10 @@ curl "{{API_URL}}/api/v1/alert_groups/I68T24C13IFW1/" \ }' ``` - - | Parameter | Required | Description | | --------- | :------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `mode` | No | Default setting is `wipe`. `wipe` will remove the payload of all Grafana OnCall group alerts. This is useful if you sent sensitive data to OnCall. All metadata will remain. `DELETE` will trigger the removal of alert groups, alerts, and all related metadata. It will also remove alert group notifications in Slack and other destinations. | - - > **NOTE:** `DELETE` can take a few moments to delete alert groups because Grafana OnCall interacts with 3rd party APIs > such as Slack. Please check objects using `GET` to be sure the data is removed. diff --git a/docs/sources/oncall-api-reference/escalation_policies.md b/docs/sources/oncall-api-reference/escalation_policies.md index 1c538759..02c740a8 100644 --- a/docs/sources/oncall-api-reference/escalation_policies.md +++ b/docs/sources/oncall-api-reference/escalation_policies.md @@ -30,8 +30,6 @@ The above command returns JSON structured in the following way: } ``` - - | Parameter | Required | Description | | ---------------------------------- | :--------------------------------------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `escalation_chain_id` | Yes | Each escalation policy is assigned to a specific escalation chain. | @@ -47,8 +45,6 @@ The above command returns JSON structured in the following way: | `notify_if_time_from` | If type = `notify_if_time_from_to` | UTC time represents the beginning of the time period, for example `09:00:00Z`. | | `notify_if_time_to` | If type = `notify_if_time_from_to` | UTC time represents the end of the time period, for example `18:00:00Z`. | - - **HTTP request** `POST {{API_URL}}/api/v1/escalation_policies/` diff --git a/docs/sources/oncall-api-reference/on_call_shifts.md b/docs/sources/oncall-api-reference/on_call_shifts.md index 74917bf0..98eeab49 100644 --- a/docs/sources/oncall-api-reference/on_call_shifts.md +++ b/docs/sources/oncall-api-reference/on_call_shifts.md @@ -41,8 +41,6 @@ The above command returns JSON structured in the following way: } ``` - - | Parameter | Unique | Required | Description | | -------------------------------- | :----: | :--------------------------------------------: | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Yes | Yes | On-call shift name. | @@ -53,7 +51,7 @@ The above command returns JSON structured in the following way: | `start` | No | Yes | Start time of the on-call shift. This parameter takes a date format as `yyyy-MM-dd'T'HH:mm:ss` (for example "2020-09-05T08:00:00"). | | `duration` | No | Yes | Duration of the event. | | `frequency` | No | If type = `recurrent_event` or `rolling_users` | One of: `hourly`, `daily`, `weekly`, `monthly`. | -| `interval` | No | Optional | This parameter takes a positive integer that represents the intervals that the recurrence rule repeats. If `frequency` is set, the default assumed value for this will be `1`. | +| `interval` | No | Optional | This parameter takes a positive integer that represents the intervals that the recurrence rule repeats. If `frequency` is set, the default assumed value for this will be `1`. | | `until` | No | Optional | When the recurrence rule ends (endless if None). This parameter takes a date format as `yyyy-MM-dd'T'HH:mm:ss` (for example "2020-09-05T08:00:00"). | | `week_start` | No | Optional | Start day of the week in iCal format. One of: `SU` (Sunday), `MO` (Monday), `TU` (Tuesday), `WE` (Wednesday), `TH` (Thursday), `FR` (Friday), `SA` (Saturday). Default: `SU`. | | `by_day` | No | Optional | List of days in iCal format. Valid values are: `SU`, `MO`, `TU`, `WE`, `TH`, `FR`, `SA`. | @@ -63,8 +61,6 @@ The above command returns JSON structured in the following way: | `rolling_users` | No | Optional | List of lists with on-call users (for `rolling_users` event type). Grafana OnCall will iterate over lists of users for every time frame specified in `frequency`. For example: there are two lists of users in `rolling_users` : [[Alex, Bob], [Alice]] and `frequency` = `daily` . This means that the first day Alex and Bob will be notified. The next day: Alice. The day after: Alex and Bob again and so on. | | `start_rotation_from_user_index` | No | Optional | Index of the list of users in `rolling_users`, from which on-call rotation starts. By default, the start index is `0` | - - Please see [RFC 5545](https://tools.ietf.org/html/rfc5545#section-3.3.10) for more information about recurrence rules. **HTTP request** diff --git a/docs/sources/oncall-api-reference/personal_notification_rules.md b/docs/sources/oncall-api-reference/personal_notification_rules.md index 01fe45d0..853cc47c 100644 --- a/docs/sources/oncall-api-reference/personal_notification_rules.md +++ b/docs/sources/oncall-api-reference/personal_notification_rules.md @@ -29,8 +29,6 @@ The above command returns JSON structured in the following way: } ``` - - | Parameter | Required | Description | | ----------- | :------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `user_id` | Yes | User ID | @@ -39,8 +37,6 @@ The above command returns JSON structured in the following way: | `duration` | Optional | A time in secs when type `wait` is chosen for `type`. | | `important` | Optional | Boolean value indicates if a rule is "important". Default is `false`. | - - **HTTP request** `POST {{API_URL}}/api/v1/personal_notification_rules/` diff --git a/docs/sources/oncall-api-reference/routes.md b/docs/sources/oncall-api-reference/routes.md index 4d8987a2..45c39ae6 100644 --- a/docs/sources/oncall-api-reference/routes.md +++ b/docs/sources/oncall-api-reference/routes.md @@ -44,10 +44,8 @@ Routes allow you to direct different alerts to different messenger channels and - Alerts for different engineering groups - Snoozing spam & debugging alerts - - | Parameter | Unique | Required | Description | -|-----------------------| :----: |:--------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| --------------------- | :----: | :------: | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `integration_id` | No | Yes | Each route is assigned to a specific integration. | | `escalation_chain_id` | No | Yes | Each route is assigned a specific escalation chain. Explicitly pass `null` to create a route without an escalation chain assigned. | | `routing_type` | Yes | No | Routing type that can be either `jinja2` or `regex`(default value) | @@ -55,8 +53,6 @@ Routes allow you to direct different alerts to different messenger channels and | `position` | Yes | Optional | Route matching is performed one after another starting from position=`0`. Position=`-1` will put the route to the end of the list before `is_the_last_route`. A new route created with a position of an existing route will move the old route (and all following routes) down in the list. | | `slack` | Yes | Optional | Dictionary with Slack-specific settings for a route. | - - **HTTP request** `POST {{API_URL}}/api/v1/routes/` diff --git a/docs/sources/oncall-api-reference/schedules.md b/docs/sources/oncall-api-reference/schedules.md index 9f9410a9..9076985c 100644 --- a/docs/sources/oncall-api-reference/schedules.md +++ b/docs/sources/oncall-api-reference/schedules.md @@ -39,8 +39,6 @@ The above command returns JSON structured in the following way: } ``` - - | Parameter | Unique | Required | Description | | -------------------- | :----: | :--------------: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `name` | Yes | Yes | Schedule name. | @@ -52,8 +50,6 @@ The above command returns JSON structured in the following way: | `slack` | No | Optional | Dictionary with Slack-specific settings for a schedule. Includes `channel_id` and `user_group_id` fields, that take a channel ID and a user group ID from Slack. | | `shifts` | No | Optional | List of shifts. Used for manually added on-call shifts in Schedules with type `calendar`. | - - **HTTP request** `POST {{API_URL}}/api/v1/schedules/` diff --git a/docs/sources/oncall-api-reference/user_groups.md b/docs/sources/oncall-api-reference/user_groups.md index b7f6e328..e8f6a806 100644 --- a/docs/sources/oncall-api-reference/user_groups.md +++ b/docs/sources/oncall-api-reference/user_groups.md @@ -36,16 +36,12 @@ The above command returns JSON structured in the following way: } ``` - - | Parameter | Unique | Description | | --------- | :----: | :---------------------------------------------------------------------------------------------------- | | `id` | Yes | User Group ID | | `type` | No | [Slack-defined user groups](https://slack.com/intl/en-ru/help/articles/212906697-Create-a-user-group) | | `slack` | No | Metadata retrieved from Slack. | - - **HTTP request** `GET {{API_URL}}/api/v1/user_groups/` diff --git a/helm/README.md b/helm/README.md index b35fd43f..698a9664 100644 --- a/helm/README.md +++ b/helm/README.md @@ -29,15 +29,11 @@ 5. Get credentials - - ```bash echo "\n\nOpen Grafana on localhost:30002 with credentials - user: admin, password: $(kubectl get secret --namespace default helm-testing-grafana -o jsonpath="{.data.admin-password}" | base64 --decode ; echo)" echo "Open Plugins -> Grafana OnCall -> fill form: backend url: http://host.docker.internal:30001" ``` - - 6. Clean up ```bash diff --git a/helm/oncall/README.md b/helm/oncall/README.md index 58ae20e9..5e49c906 100644 --- a/helm/oncall/README.md +++ b/helm/oncall/README.md @@ -45,8 +45,6 @@ helm install \ Follow the `helm install` output to finish setting up Grafana OnCall backend and Grafana OnCall frontend plugin e.g. - - ```bash 👋 Your Grafana OnCall instance has been successfully deployed @@ -74,8 +72,6 @@ Follow the `helm install` output to finish setting up Grafana OnCall backend and 🎉🎉🎉 Done! 🎉🎉🎉 ``` - - ## Configuration You can edit values.yml to make changes to the helm chart configuration and re-deploy the release with the following command: diff --git a/tools/pagerduty-migrator/README.md b/tools/pagerduty-migrator/README.md index e60a7500..143add77 100644 --- a/tools/pagerduty-migrator/README.md +++ b/tools/pagerduty-migrator/README.md @@ -107,11 +107,9 @@ webhook integrations to adjust them for incoming payloads. Configuration is done via environment variables passed to the docker container. - - | Name | Description | Type | Default | -|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------|---------| -| `PAGERDUTY_API_TOKEN` | PagerDuty API **user token**. To create a token, refer to [PagerDuty docs](). | String | N/A | +| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------- | ------- | +| `PAGERDUTY_API_TOKEN` | PagerDuty API **user token**. To create a token, refer to [PagerDuty docs](https://support.pagerduty.com/docs/api-access-keys#generate-a-user-token-rest-api-key). | String | N/A | | `ONCALL_API_URL` | Grafana OnCall API URL. This can be found on the "Settings" page of your Grafana OnCall instance. | String | N/A | | `ONCALL_API_TOKEN` | Grafana OnCall API Token. To create a token, navigate to the "Settings" page of your Grafana OnCall instance. | String | N/A | | `MODE` | Migration mode (plan vs actual migration). | String (choices: `plan`, `migrate`) | `plan` | @@ -120,8 +118,6 @@ Configuration is done via environment variables passed to the docker container. | `EXPERIMENTAL_MIGRATE_EVENT_RULES` | Migrate global event rulesets to Grafana OnCall integrations. | Boolean | `false` | | `EXPERIMENTAL_MIGRATE_EVENT_RULES_LONG_NAMES` | Include service & integrations names from PD in migrated integrations (only effective when `EXPERIMENTAL_MIGRATE_EVENT_RULES` is `true`). | Boolean | `false` | - - ## Resources ### User notification rules @@ -144,11 +140,11 @@ The tool is capable of migrating on-call schedules from PagerDuty to Grafana OnC There are two ways to migrate on-call schedules: - Migrate on-call shifts as if they were created in Grafana OnCall web UI. Due to scheduling differences between -PagerDuty and Grafana OnCall, it's sometimes impossible to automatically migrate on-call shifts without manual changes -in PD. Pass `SCHEDULE_MIGRATION_MODE=web` to the tool to enable this mode. + PagerDuty and Grafana OnCall, it's sometimes impossible to automatically migrate on-call shifts without manual changes + in PD. Pass `SCHEDULE_MIGRATION_MODE=web` to the tool to enable this mode. - Using ICalendar file URLs from PagerDuty. This way it's always possible to migrate schedules without any manual -changes in PD, but resulting schedules in Grafana OnCall will be read-only. Pass `SCHEDULE_MIGRATION_MODE=ical` to the tool -to enable this mode. + changes in PD, but resulting schedules in Grafana OnCall will be read-only. Pass `SCHEDULE_MIGRATION_MODE=ical` to + the tool to enable this mode. On-call schedules will be migrated to new Grafana OnCall schedules with the same name as in PD. Any existing schedules with the same name will be deleted before migration. Any on-call schedules that reference unmatched users won't be @@ -197,4 +193,4 @@ but it can also make the names of integrations too long. - Connect integrations (press the "How to connect" button on the integration page) - Make sure users connect their phone numbers, Slack accounts, etc. in their user settings - When using `SCHEDULE_MIGRATION_MODE=ical`, at some point you would probably want to recreate schedules using -Google Calendar or Terraform to be able to modify migrated on-call schedules in Grafana OnCall + Google Calendar or Terraform to be able to modify migrated on-call schedules in Grafana OnCall