| `job_waiter_started_total` | Counter | 12.9 | Number of batches of jobs started where a web request is waiting for the jobs to complete | worker |
| `job_waiter_timeouts_total` | Counter | 12.9 | Number of batches of jobs that timed out where a web request is waiting for the jobs to complete | worker |
| `gitlab_database_transaction_seconds` | Histogram | 12.1 | Time spent in database transactions, in seconds | |
| `gitlab_database_transaction_seconds` | Histogram | 12.1 | Time spent in database transactions, in seconds | |
| `queue_name` | string | yes | The name of the queue to delete jobs from |
| `user` | string | no | The username of the user who scheduled the jobs |
| `project` | string | no | The full path of the project where the jobs were scheduled from |
| `root_namespace` | string | no | The root namespace of the project |
| `subscription_plan` | string | no | The subscription plan of the root namespace (GitLab.com only) |
| `caller_id` | string | no | The endpoint or background job that schedule the job (for example: `ProjectsController#create`, `/api/:version/projects/:id`, `PostReceive`) |
At least one attribute, other than `queue_name`, is required.
[validation, and coercion of the parameters]:https://github.com/ruby-grape/grape#parameter-validation-and-coercion
[validation, and coercion of the parameters]:https://github.com/ruby-grape/grape#parameter-validation-and-coercion
[installing GitLab under a relative URL]:https://docs.gitlab.com/ee/install/relative_url.html
[installing GitLab under a relative URL]:https://docs.gitlab.com/ee/install/relative_url.html
## Testing
When writing tests for new API endpoints, consider using a schema [fixture](./testing_guide/best_practices.md#fixtures) located in `/spec/fixtures/api/schemas`. You can `expect` a response to match a given schema:
@@ -202,13 +202,10 @@ create the actual RDS instance.
...
@@ -202,13 +202,10 @@ create the actual RDS instance.
### RDS Subnet Group
### RDS Subnet Group
1. Navigate to the RDS dashboard and select **Subnet Groups** from the left menu.
1. Navigate to the RDS dashboard and select **Subnet Groups** from the left menu.
1. Give it a name (`gitlab-rds-group`), a description, and choose the VPC from
1. Click on **Create DB Subnet Group**.
the VPC dropdown.
1. Under **Subnet group details**, enter a name (we'll use `gitlab-rds-group`), a description, and choose the `gitlab-vpc` from the VPC dropdown.
1. Click "Add all the subnets related to this VPC" and
1. Under **Add subnets**, click **Add all the subnets related to this VPC** and remove the public ones, we only want the **private subnets**. In the end, you should see `10.0.1.0/24` and `10.0.3.0/24` (as we defined them in the [subnets section](#subnets)).
remove the public ones, we only want the **private subnets**.
1. Click **Create** when ready.
In the end, you should see `10.0.1.0/24` and `10.0.3.0/24` (as
we defined them in the [subnets section](#subnets)).
Click **Create** when ready.
...
@@ -217,33 +214,31 @@ create the actual RDS instance.
...
@@ -217,33 +214,31 @@ create the actual RDS instance.
Now, it's time to create the database:
Now, it's time to create the database:
1. Select **Databases** from the left menu and click **Create database**.
1. Select **Databases** from the left menu and click **Create database**.
1. Select PostgreSQL and click **Next**.
1. Select **Standard Create** for the database creation method.
1. Since this is a production server, let's choose "Production". Click **Next**.
1. Select **PostgreSQL** as the database engine and select **PostgreSQL 10.9-R1** from the version dropdown menu (check the [database requirements](../../install/requirements.md#postgresql-requirements) to see if there are any updates on this for your chosen version of GitLab).
1. Let's see the instance specifications:
1. Since this is a production server, let's choose **Production** from the **Templates** section.
1. Leave the license model as is (`postgresql-license`).
1. Under **Settings**, set a DB instance identifier, a master username, and a master password. We'll use `gitlab-db-ha`, `gitlab`, and a very secure password respectively. Make a note of these as we'll need them later.
1. For the version, select the latest of the 9.6 series (check the
1. For the DB instance size, select **Standard classes** and select an instance size that meets your requirements from the dropdown menu. We'll use a `db.m4.large` instance.
1. Select **Provisioned IOPS (SSD)** from the storage type dropdown menu. Provisioned IOPS (SSD) storage is best suited for HA (though you can choose General Purpose (SSD) to reduce the costs). Read more about it at [Storage for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
1. For the size, let's select a `t2.medium` instance.
1. Allocate storage and set provisioned IOPS. We'll use the minimum values, `100` and `1000`, respectively.
1. Multi-AZ-deployment is recommended as redundancy, so choose "Create
1. Enable storage autoscaling (optional) and set a maximum storage threshold.
replica in different zone". Read more at
1. Under **Availability & durability**, select **Create a standby instance** to have a standby RDS instance provisioned in a different Availability Zone. Read more at [High Availability (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html).
# This test is quarantined because the use of magic number 999 causes failure on CI
# This test is quarantined because the use of magic number 999 causes failure on CI
it'does not set params that are excluded from import_export settings',quarantine: 'https://gitlab.com/gitlab-org/gitlab/issues/207932#note_293724442'do
it'does not set params that are excluded from import_export settings',quarantine: 'https://gitlab.com/gitlab-org/gitlab/issues/207932#note_293724442'do
