7 files changed, 46 insertions, 21 deletions

diff --git a/app/assets/images/select2-spinner.gif b/app/assets/images/select2-spinner.gif
index 5b33f7e54f4..5b33f7e54f4 100755..100644
--- a/app/assets/images/select2-spinner.gif
+++ b/app/assets/images/select2-spinner.gif
diff --git a/app/assets/images/select2.png b/app/assets/images/select2.png
index 1d804ffb996..1d804ffb996 100755..100644
--- a/app/assets/images/select2.png
+++ b/app/assets/images/select2.png
diff --git a/app/assets/images/select2x2.png b/app/assets/images/select2x2.png
index 4bdd5c961d4..4bdd5c961d4 100755..100644
--- a/app/assets/images/select2x2.png
+++ b/app/assets/images/select2x2.png
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 288ce376687..17d72b96a51 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -125,7 +125,7 @@ The Pages daemon doesn't listen to the outside world.
     pages_external_url 'http://example.io'
     ```
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
 
 Watch the [video tutorial][video-admin] for this configuration.
 
@@ -157,7 +157,22 @@ outside world.
     where `pages-nginx.crt` and `pages-nginx.key` are the SSL cert and key,
     respectively.
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
+
+### Additional configuration for Docker container
+
+The GitLab Pages daemon will not have permissions to bind mounts when it runs
+in a Docker container. To overcome this issue you'll need to change the chroot
+behavior:
+
+1. Edit `/etc/gitlab/gitlab.rb`.
+1. Set the `inplace_chroot` to `true` for GitLab Pages:
+
+    ```shell
+    gitlab_pages['inplace_chroot'] = true
+    ```
+
+1. [Reconfigure GitLab][reconfigure].
 
 ## Advanced configuration
 
@@ -195,7 +210,7 @@ world. Custom domains are supported, but no TLS.
     `192.0.2.2` and `2001::2` are the secondary IPs the GitLab Pages daemon
     listens on. If you don't have IPv6, you can omit the IPv6 address.
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
 
 ### Custom domains with TLS support
 
@@ -229,7 +244,7 @@ world. Custom domains and TLS are supported.
     `192.0.2.2` and `2001::2` are the secondary IPs where the GitLab Pages daemon
     listens on. If you don't have IPv6, you can omit the IPv6 address.
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
 
 ### Custom domain verification
 
@@ -287,7 +302,7 @@ Follow the steps below to configure verbose logging of GitLab Pages daemon.
     gitlab_pages['log_verbose'] = true
     ```
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
 
 ## Change storage path
 
@@ -302,7 +317,7 @@ are stored.
     gitlab_rails['pages_path'] = "/mnt/storage/pages"
     ```
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
 
 ## Configure listener for reverse proxy requests
 
@@ -325,7 +340,7 @@ Omnibus GitLab 11.1.
     gitlab_pages['listen_proxy'] = "localhost:10080"
     ```
 
-1. [Reconfigure GitLab][reconfigure]
+1. [Reconfigure GitLab][reconfigure].
 
 ## Set maximum pages size
 
diff --git a/doc/api/services.md b/doc/api/services.md
index 03d0a80aa64..1f84e2de7de 100644
--- a/doc/api/services.md
+++ b/doc/api/services.md
@@ -522,7 +522,7 @@ Parameters:
 | `username`      | string | yes  | The username of the user created to be used with GitLab/JIRA. |
 | `password`      | string | yes  | The password of the user created to be used with GitLab/JIRA. |
 | `active`        | boolean | no  | Activates or deactivates the service. Defaults to false (deactivated). |
-| `jira_issue_transition_id` | integer | no | The ID of a transition that moves issues to a closed state. You can find this number under the JIRA workflow administration (**Administration > Issues > Workflows**) by selecting **View** under **Operations** of the desired workflow of your project. The ID of each state can be found inside the parenthesis of each transition name under the **Transitions (id)** column ([see screenshot][trans]). By default, this ID is set to `2`. |
+| `jira_issue_transition_id` | string | no | The ID of a transition that moves issues to a closed state. You can find this number under the JIRA workflow administration (**Administration > Issues > Workflows**) by selecting **View** under **Operations** of the desired workflow of your project. The ID of each state can be found inside the parenthesis of each transition name under the **Transitions (id)** column ([see screenshot][trans]). By default, this ID is set to `2`. |
 
 ### Delete JIRA service
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 9eb694a2c64..3e6e89052f8 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -499,9 +499,9 @@ docker build:
       - more_scripts/*.{rb,py,sh}
 ```
 
-In the scenario above, if you are pushing multiple commits to GitLab to an
-existing branch, GitLab creates and triggers the `docker build` job, provided that
-one of the commits contains changes to either:
+In the scenario above, when pushing multiple commits to GitLab to an existing
+branch, GitLab creates and triggers `docker build` job, provided that one of the
+commits contains changes to either:
 
 - The `Dockerfile` file.
 - Any of the files inside `docker/scripts/` directory.
@@ -514,21 +514,20 @@ the section below.
 
 ##### Using `changes` with new branches and tags
 
-If you are pushing a **new** branch or a **new** tag to GitLab, the policy
-always evaluates to true and GitLab will create a job. This feature is not
-connected with merge requests yet, and because GitLab is creating pipelines
-before an user can create a merge request we don't know a target branch at
-this point.
+When pushing a **new** branch or a **new** tag to GitLab, the policy always
+evaluates to true and GitLab will create a job. This feature is not connected
+with merge requests yet and, because GitLab is creating pipelines before a user
+can create a merge request, it is unknown what the target branch is at this point.
 
 ##### Using `changes` with `merge_requests`
 
 With [pipelines for merge requests](../merge_request_pipelines/index.md),
-make it possible to define if a job should be created base on files modified
+it is possible to define a job to be created based on files modified
 in a merge request.
 
 For example:
 
-```
+```yaml
 docker build service one:
   script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
   only:
@@ -539,9 +538,9 @@ docker build service one:
       - service-one/**/*
 ```
 
-In the scenario above, if you create or update a merge request that changes
-either files in `service-one` folder or `Dockerfile`, GitLab creates and triggers
-the `docker build service one` job.
+In the scenario above, if a merge request is created or updated that changes
+either files in `service-one` directory or the `Dockerfile`, GitLab creates
+and triggers the `docker build service one` job.
 
 ### `tags`
 
diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md
index 3fb553280d0..5aa72edac14 100644
--- a/doc/workflow/lfs/lfs_administration.md
+++ b/doc/workflow/lfs/lfs_administration.md
@@ -108,6 +108,17 @@ Here is a configuration example with GCS.
 
 _NOTE: The service account must have permission to access the bucket. [See more](https://cloud.google.com/storage/docs/authentication)_
 
+Here is a configuration example with Rackspace Cloud Files.
+| Setting | Description | example |
+|---------|-------------|---------|
+| `provider` | The provider name | `Rackspace` |
+| `rackspace_username` | The username of the Rackspace account with access to the container | `joe.smith` |
+| `rackspace_api_key` | The API key of the Rackspace account with access to the container | `ABC123DEF456ABC123DEF456ABC123DE` |
+| `rackspace_region` | The Rackspace storage region to use, a three letter code from the [list of service access endpoints](https://developer.rackspace.com/docs/cloud-files/v1/general-api-info/service-access/) | `iad` |
+| `rackspace_temp_url_key` | The private key you have set in the Rackspace API for temporary URLs. Read more [here](https://developer.rackspace.com/docs/cloud-files/v1/use-cases/public-access-to-your-cloud-files-account/#tempurl) | `ABC123DEF456ABC123DEF456ABC123DE` |
+
+_NOTES: Regardless of whether the container has public access enabled or disabled, Fog will use the TempURL method to grant access to LFS objects. If you see errors in logs referencing instantiating storage with a temp-url-key, ensure that you have set they key properly on the Rackspace API and in gitlab.rb. You can verify the value of the key Rackspace has set by sending a GET request with token header to the service access endpoint URL and comparing the output of the returned headers._
+
 ### Manual uploading to an object storage
 
 There are two ways to manually do the same thing as automatic uploading (described above).