Merge branch 'master' into update-todo-in-uiupdate-todo-in-ui

* master: (435 commits)
  Change occurrence of Sidekiq::Testing.inline!
  Fix order-dependent spec failure in appearance_spec.rb
  Put a failed example from appearance_spec in quarantine
  Cache PerformanceBar.allowed_user_ids list locally and in Redis
  Add Grafana to Admin > Monitoring menu when enabled
  Add changelog entry
  Add salesforce logo
  Move error_tracking_frontend specs to Jest
  Only save Peek session in Redis when Peek is enabled
  Migrate markdown header_spec.js to Jest
  Fix golint command in Go guide doc to be recursive
  Move images to their own dirs
  Gitlab -> GitLab
  Re-align CE and EE API docs
  Rename Release groups in issue_workflow.md
  Update api docs to finish aligning EE and CE docs
  Update locale.pot
  Update TODO: allow_collaboration column renaming
  Show upcoming status for releases
  Rebased and squashed commits
  ...

4 files changed, 334 insertions, 16 deletions

diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index a0fe97f2b9d..d21455fb5ca 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -222,7 +222,7 @@ functionalities needed to successfully build and deploy a containerized
 application. Bear in mind that the same credentials are used for all the
 applications running on the cluster.
 
-## Gitlab-managed clusters
+## GitLab-managed clusters
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22011) in GitLab 11.5.
 > Became [optional](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/26565) in GitLab 11.11.
@@ -519,8 +519,11 @@ service account of the cluster integration.
 
 ### Troubleshooting failed deployment jobs
 
-GitLab will create a namespace and service account specifically for your
-deployment jobs. This happens immediately before the deployment job starts.
+Before the deployment jobs starts, GitLab creates the following specifically for
+the deployment job:
+
+- A namespace.
+- A service account.
 
 However, sometimes GitLab can not create them. In such instances, your job will fail with the message:
 
@@ -530,22 +533,20 @@ This job failed because the necessary resources were not successfully created.
 
 To find the cause of this error when creating a namespace and service account, check the [logs](../../../administration/logs.md#kuberneteslog).
 
-NOTE: **NOTE:**
-As of GitLab 12.1 we require [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
-tokens for all project level clusters unless you unselect the
-[GitLab-managed cluster](#gitlab-managed-clusters) option. If you
-want to manage namespaces and service accounts yourself and don't
-want to provide a `cluster-admin` token to GitLab you must unselect this
-option or you will get the above error.
-
-Common reasons for failure include:
+Reasons for failure include:
 
-- The token you gave GitLab did not have [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
+- The token you gave GitLab does not have [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
   privileges required by GitLab.
 - Missing `KUBECONFIG` or `KUBE_TOKEN` variables. To be passed to your job, they must have a matching
   [`environment:name`](../../../ci/environments.md#defining-environments). If your job has no
   `environment:name` set, it will not be passed the Kubernetes credentials.
 
+NOTE: **NOTE:**
+Project-level clusters upgraded from GitLab 12.0 or older may be configured
+in a way that causes this error. Ensure you deselect the
+[GitLab-managed cluster](#gitlab-managed-clusters) option if you want to manage
+namespaces and service accounts yourself.
+
 ## Monitoring your Kubernetes cluster **[ULTIMATE]**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/4701) in [GitLab Ultimate][ee] 10.6.
diff --git a/doc/user/project/clusters/kubernetes_pod_logs.md b/doc/user/project/clusters/kubernetes_pod_logs.md
index 368031070c1..25d8abebf07 100644
--- a/doc/user/project/clusters/kubernetes_pod_logs.md
+++ b/doc/user/project/clusters/kubernetes_pod_logs.md
@@ -12,9 +12,9 @@ By displaying the logs directly in GitLab, developers can avoid having to manage
 1. Go to **Operations > Environments** and find the environment which contains the desired pod, like `production`.
 1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md).
 1. When mousing over the list of pods, a tooltip will appear with the exact pod name and status.
-![Deploy Boards pod list](img/pod_logs_deploy_board.png)
+   ![Deploy Boards pod list](img/pod_logs_deploy_board.png)
 1. Click on the desired pod to bring up the logs view, which will contain the last 500 lines for that pod. Support for pods with multiple containers is coming [in a future release](https://gitlab.com/gitlab-org/gitlab-ee/issues/6502).
-![Deploy Boards pod list](img/kubernetes_pod_logs.png)
+   ![Deploy Boards pod list](img/kubernetes_pod_logs.png)
 
 ## Requirements
 
diff --git a/doc/user/project/clusters/serverless/img/function-endpoint.png b/doc/user/project/clusters/serverless/img/function-endpoint.png
new file mode 100644
index 00000000000..f3c7ae7a00d
--- /dev/null
+++ b/doc/user/project/clusters/serverless/img/function-endpoint.png
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index 3be5bfeaddc..a06c3d3c662 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -94,10 +94,55 @@ adding an existing installation of Knative.
 It is also possible to use GitLab Serverless with an existing Kubernetes
 cluster which already has Knative installed.
 
-Simply:
+You must do the following:
 
 1. Follow the steps to
    [add an existing Kubernetes cluster](../index.md#adding-an-existing-kubernetes-cluster).
+
+1. Ensure GitLab can manage Knative:
+    - For a non-GitLab managed cluster, ensure that the service account for the token
+      provided can manage resources in the `serving.knative.dev` API group.
+    - For a GitLab managed cluster,
+      GitLab uses a service account with the `edit` cluster role. This account needs
+      the ability to manage resources in the `serving.knative.dev` API group.
+      We suggest you do this with an [aggregated ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles)
+      adding rules to the default `edit` cluster role:
+      First, save the following YAML as `knative-serving-only-role.yaml`:
+
+      ```yaml
+      apiVersion: rbac.authorization.k8s.io/v1
+      kind: ClusterRole
+      metadata:
+        name: knative-serving-only-role
+        labels:
+          rbac.authorization.k8s.io/aggregate-to-edit: "true"
+      rules:
+      - apiGroups:
+        - serving.knative.dev
+        resources:
+        - configurations
+        - configurationgenerations
+        - routes
+        - revisions
+        - revisionuids
+        - autoscalers
+        - services
+        verbs:
+        - get
+        - list
+        - create
+        - update
+        - delete
+        - patch
+        - watch
+        ```
+
+        Then run the following command:
+
+        ```bash
+        kubectl apply -f knative-serving-only-role.yaml
+        ```
+
 1. Follow the steps to deploy [functions](#deploying-functions)
    or [serverless applications](#deploying-serverless-applications) onto your
    cluster.
@@ -325,3 +370,275 @@ loading or is not available at this time._  It will appear upon the first access
 page, but should go away after a few seconds. If the message does not disappear, then it
 is possible that GitLab is unable to connect to the Prometheus instance running on the
 cluster.
+
+## Enabling TLS for Knative services
+
+By default, a GitLab serverless deployment will be served over `http`. In order to serve over `https` you
+must manually obtain and install TLS certificates.
+
+The simplest way to accomplish this is to 
+use [Certbot to manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates). Certbot is a free, open source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.
+
+NOTE: **Note:**
+The instructions below relate to installing and running Certbot on a Linux server and may not work on other operating systems.
+
+1. Install Certbot by running the 
+   [`certbot-auto` wrapper script](https://certbot.eff.org/docs/install.html#certbot-auto).
+   On the command line of your server, run the following commands:
+
+    ```sh
+    wget https://dl.eff.org/certbot-auto
+    sudo mv certbot-auto /usr/local/bin/certbot-auto
+    sudo chown root /usr/local/bin/certbot-auto
+    chmod 0755 /usr/local/bin/certbot-auto
+    /usr/local/bin/certbot-auto --help
+    ```
+
+    To check the integrity of the `certbot-auto` script, run:
+
+      ```sh
+      wget -N https://dl.eff.org/certbot-auto.asc
+      gpg2 --keyserver ipv4.pool.sks-keyservers.net --recv-key A2CFB51FA275A7286234E7B24D17C995CD9775F2
+      gpg2 --trusted-key 4D17C995CD9775F2 --verify certbot-auto.asc /usr/local/bin/certbot-auto
+      ```
+
+    The output of the last command should look something like:
+
+      ```sh
+      gpg: Signature made Mon 10 Jun 2019 06:24:40 PM EDT
+      gpg:                using RSA key A2CFB51FA275A7286234E7B24D17C995CD9775F2
+      gpg: key 4D17C995CD9775F2 marked as ultimately trusted
+      gpg: checking the trustdb
+      gpg: marginals needed: 3  completes needed: 1  trust model: pgp
+      gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
+      gpg: next trustdb check due at 2027-11-22
+      gpg: Good signature from "Let's Encrypt Client Team <letsencrypt-client@eff.org>" [ultimate]
+      ```
+
+1. Run the following command to use Certbot to request a certificate
+   using DNS challenge during authorization:
+
+
+    ```sh
+    ./certbot-auto certonly --manual --preferred-challenges dns -d '*.<namespace>.example.com'
+    ```
+
+    Where `<namespace>` is the namespace created by GitLab for your serverless project (composed of `<projectname+id>`) and
+    `example.com` is the domain being used for your project. If you are unsure what the namespace of your project is, navigate
+    to the **Operations > Serverless** page of your project and inspect
+    the endpoint provided for your function/app.
+
+    ![function_endpoint](img/function-endpoint.png)
+
+    In the above image, the namespace for the project is `node-function-11909507` and the domain is `knative.info`, thus
+    certificate request line would look like this:
+
+    ```sh
+    ./certbot-auto certonly --manual --preferred-challenges dns -d '*.node-function-11909507.knative.info'
+    ```
+
+    The Certbot tool walks you through the steps of validating that you own each domain that you specify by creating TXT records in those domains.
+    After this process is complete, the output should look something like this:
+
+    ```sh
+    IMPORTANT NOTES:
+    - Congratulations! Your certificate and chain have been saved at:
+      /etc/letsencrypt/live/namespace.example.com/fullchain.pem
+      Your key file has been saved at:
+      /etc/letsencrypt/live/namespace.example/privkey.pem
+      Your cert will expire on 2019-09-19. To obtain a new or tweaked
+      version of this certificate in the future, simply run certbot-auto
+      again. To non-interactively renew *all* of your certificates, run
+      "certbot-auto renew"
+    -----BEGIN PRIVATE KEY-----
+    - Your account credentials have been saved in your Certbot
+      configuration directory at /etc/letsencrypt. You should make a
+      secure backup of this folder now. This configuration directory will
+      also contain certificates and private keys obtained by Certbot so
+      making regular backups of this folder is ideal.
+    ```
+
+1. Create certificate and private key files. Using the contents of the files
+   returned by Certbot, we'll create two files in order to create the
+   Kubernetes secret:
+
+      Run the following command to see the contents of `fullchain.pem`:
+
+      ```sh
+      sudo cat /etc/letsencrypt/live/node-function-11909507.knative.info/fullchain.pem
+      ```
+
+      Output should look like this:
+
+      ```sh
+      -----BEGIN CERTIFICATE-----
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b4ag==
+      -----END CERTIFICATE-----
+      -----BEGIN CERTIFICATE-----
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      K2fcb195768c39e9a94cec2c2e30Qg==
+      -----END CERTIFICATE-----
+      ```
+
+      Create a file with the name `cert.pem` with the contents of the entire output.
+
+      Once `cert.pem` is created, run the following command to see the contents of `privkey.pem`:
+
+      ```sh
+      sudo cat /etc/letsencrypt/live/namespace.example/privkey.pem
+      ```
+
+      Output should look like this:
+
+      ```sh
+      -----BEGIN PRIVATE KEY-----
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      2fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      04f294d1eaca42b8692017b426d53bbc8fe75f827734f0260710b83a556082df
+      -----BEGIN CERTIFICATE-----
+      fcb195768c39e9a94cec2c2e32c59c0aad7a3365c10892e8116b5d83d4096b6
+      4f294d1eaca42b8692017b4262==
+      -----END PRIVATE KEY-----
+      ```
+
+      Create a new file with the name `cert.pk` with the contents of the entire output.
+
+1. Create a Kubernetes secret to hold your TLS certificate, `cert.pem`, and
+   the private key `cert.pk`:
+
+    NOTE: **Note:**
+    Running `kubectl` commands on your cluster requires setting up access to the cluster first.
+    For clusters created on GKE, see
+    [GKE Cluster Access](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl).
+    For other platforms, [install `kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
+
+    ```sh
+    kubectl create --namespace istio-system secret tls istio-ingressgateway-certs \
+    --key cert.pk \
+    --cert cert.pem
+    ```
+
+    Where `cert.pem` and `cert.pk` are your certificate and private key files. Note that the `istio-ingressgateway-certs` secret name is required.
+
+1. Configure Knative to use the new secret that you created for HTTPS
+   connections. Run the 
+  following command to open the Knative shared `gateway` in edit mode:
+
+    ```sh
+    kubectl edit gateway knative-ingress-gateway --namespace knative-serving
+    ```
+
+      Update the gateway to include the following tls: section and configuration:
+
+      ```sh
+      tls:
+        mode: SIMPLE
+        privateKey: /etc/istio/ingressgateway-certs/tls.key
+        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
+      ```
+
+      Example:
+
+      ```sh
+      apiVersion: networking.istio.io/v1alpha3
+      kind: Gateway
+      metadata:
+        # ... skipped ...
+      spec:
+        selector:
+          istio: ingressgateway
+        servers:
+          - hosts:
+              - "*"
+            port:
+              name: http
+              number: 80
+              protocol: HTTP
+          - hosts:
+              - "*"
+            port:
+              name: https
+              number: 443
+              protocol: HTTPS
+            tls:
+              mode: SIMPLE
+              privateKey: /etc/istio/ingressgateway-certs/tls.key
+              serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
+      ```
+
+      After your changes are running on your Knative cluster, you can begin using the HTTPS protocol for secure access your deployed Knative services.
+      In the event a mistake is made during this process and you need to update the cert, you will need to edit the gateway `knative-ingress-gateway`
+      to switch back to `PASSTHROUGH` mode. Once corrections are made, edit the file again so the gateway will use the new certificates.
\ No newline at end of file