GitLab Enterprise Edition issueshttps://gitlab.com/gitlab-org/gitlab-ee/issues2018-11-06T10:54:49Zhttps://gitlab.com/gitlab-org/gitlab-ee/issues/7569Credential rotation / dynamic secrets / secret variables2018-11-06T10:54:49ZMark PundsackCredential rotation / dynamic secrets / secret variables### Problem to solve
Users need secure passwords/tokens, and an additional layer of security is to automatically rotate those credentials so that if any were leaked, they'd be ineffective soon enough anyway.
### Further details
Many users use Vault for this purpose, but we should build in credential rotation into GitLab's variables. This implies we have one or more first-class types of credentials first. e.g. Create a variable that is a 35-character alphanumeric password.
### Proposal
### What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)
### Links / referencesBacklogAccepting merge requestsConfigureProduct Vision 2019application control panelci variablesdevops:configuredirectionfeature proposalhttps://gitlab.com/gitlab-org/gitlab-ee/issues/3585Application idling / scale to zero2018-10-31T04:33:27ZMark PundsackApplication idling / scale to zero### Description
One of the great things about Heroku is that free apps idle when not in use. This helps control costs significantly, with only a small delay when an app spins up. (~12 seconds)
If we ever offer compute on GitLab.com, or for enterprises making heavy use of review apps while wanting to control their costs, we should support some way to scale apps down to 0 pods and automatically spin them back up when they are needed.
Note, this gets really complicated if your scale is greater than 1. Heroku only lets you idle on 1-dyno apps, for example. Now, it's possible it doesn't have to be that complicated, and Kubernetes has horizontal autoscaling based on CPU, so theoretically, once it's scaled down to 1, we can further detect that it's truly idle, and scale it down to 0.
### Proposal
* Building on https://gitlab.com/gitlab-org/gitlab-ce/issues/38543,
* Add checkbox to enabled idling (perhaps only if scale it set to 1, or if autoscale min=1)
* Add group and instance configurations to enable idling by default (or maybe we just enable it for default always)
* NGINX on Kubernetes is configured to route requests to the default backend if there are no services/pods to take the requests
* Replace default backend with a server that takes the requests, holds them, edits the appropriate service to scale the replica set from 0 to 1, and when the pod comes up, redirect/route the request to the new pod.
* Optionally display an interstitial explaining what is happening (but this only works for HTML resources, not API requests, for example)
* Have a reaper that puts services to sleep when they've been idle for 1 hour
### Links / references
### Documentation blurb
#### Overview
What is it?
Why should someone use this feature?
What is the underlying (business) problem?
How do you use this feature?
#### Use cases
Who is this for? Provide one or more use cases.
### Feature checklist
Make sure these are completed before closing the issue,
with a link to the relevant commit.
- [ ] [Feature assurance](https://about.gitlab.com/handbook/product/#feature-assurance)
- [ ] Documentation
- [ ] Added to [features.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml)12.0Accepting merge requestsConfigureGitLab Premiumapplication control paneldevopsdevops:configuredirectionfeature proposalhttps://gitlab.com/gitlab-org/gitlab-ee/issues/3584Autoscaling apps2018-10-31T04:33:27ZMark PundsackAutoscaling apps### Description
Auto DevOps let's you set application scale using `PRODUCTION_REPLICAS`. We should make it easy to autoscale application replicas. Kubernetes has a concept of [horizontal pod autoscaling](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (not to be confused with autoscaling the k8s nodes, like GKE has, currently in Beta). e.g.:
```
kubectl autoscale rc foo --min=2 --max=5 --cpu-percent=80
```
### Proposal
* Building on https://gitlab.com/gitlab-org/gitlab-ce/issues/38543,
* Add a checkbox to enable autoscaling, set min and max values
* Possibly let users choose different autoscaling algorithms or criteria
* Expose these new values as variables
### Links / references
### Documentation blurb
#### Overview
What is it?
Why should someone use this feature?
What is the underlying (business) problem?
How do you use this feature?
#### Use cases
Who is this for? Provide one or more use cases.
### Feature checklist
Make sure these are completed before closing the issue,
with a link to the relevant commit.
- [ ] [Feature assurance](https://about.gitlab.com/handbook/product/#feature-assurance)
- [ ] Documentation
- [ ] Added to [features.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml)12.0Accepting merge requestsConfigureGitLab Premiumapplication control paneldeploydevopsdevops:configuredirectionfeature proposalhttps://gitlab.com/gitlab-org/gitlab-ee/issues/6312Scale deployments directly from the environment page2018-10-31T04:33:27ZMark PundsackScale deployments directly from the environment page### Owners
UX: ?
FE: ?
BE: @matteeyah
### Description
Auto DevOps can leverage variables to define how many pods should be created during a deployment (`PRODUCTION_REPLICAS`, `CANARY_PRODUCTION_REPLICAS`, etc.): https://docs.gitlab.com/ee/topics/autodevops/#advanced-replica-variables-setup.
We should espose this variables in the **CI/CD > Environments** page, and allow users to easily change this values in the UI. After the change, we can automate the redeployment to apply the new number of requested pods.
### Original proposal
<details>
In the **CI/CD > Environments** view, for each deployment we can show
1. number of pods (e.g., `PRODUCTION_REPLICAS`)
1. if canaries are configured, number of canary pods (e.g., `CANARY_PRODUCTION_REPLICAS`)
1. if a deploy action is available in the related pipeline:
1. make it easy to change the values in the UI (since they are numbers, edit field with arrows to increase/decrease)
1. allow saving the new values, and automatically redeploy the application to apply the new values
This should support also environment-specific variables (related to https://gitlab.com/gitlab-org/gitlab-ce/issues/41436) in a transparent way for the user.
In the UI, we should make users aware that this flow works if they are using Auto DevOps, or if they implement a similar logic in their deployment jobs. It will link to documentation on how to leverage environment variables to deploy applications with a specific number of pods.
</details>
### Proposal
A new `Scale deployment` link is added next to the `Instances` title for each environment:
![scale-apps](/uploads/c92b6bed89479100f1498b344787b2bc/scale-apps.png)
When the link is clicked, the deploy board section is expanded inline to show the scaling options. The `Scale deployment` link is no longer available since we have entered scaling mode.
A message is shown at the top of the new section to inform users that this feature only works with certain configurations:
> Please, make sure your deployment job is compatible with scaling. Read [our documentation]() for more details.
TODO: Determine the documentation link
Below, the new option is shown. The description text informs the user that this change will affect deployments that happen after they save:
> Increase or decrease the number of instances used for this environment. This will affect future deployments.
The actual value is edited through a text field with arrow controls for easy modification.
Finally, there is a `Save` and `Cancel` button.
If the user collapses the environment, this section should be collapsed along with the rest of the deploy board.
![scale-apps--expanded](/uploads/943fbe6b6d8c1f14ace31189363ec64f/scale-apps--expanded.png)
We will check whether the configuration is compatible with deployment scaling:
>>>
1. Create `environment_scaling` that is gonna have all scaling options,
1. We gonna update `enviroment_scaling` once show the page,
1. We forbid updating `environment_scaling` if you have `PRODUCTION_REPLICAS` (for ex.) set as Secret Variable, as this is conflicting,
1. We show the error message, linking to edit of Secret Variables, the user deletes them, save, gets back to this page, clicks save and it's done,
1. We make `environment_scaling` to be included in variables sent to the runner.
>>>
If we detect that the configuration is incompatible, the default message is hidden and we show this message in a warning box:
> Some of the [secret variables]() in this project are incompatible with deployment scaling. Read [our documentation]() for more details.
[Secret variables]() will link to `project/settings/ci_cd`
TODO: Determine which docs page to link to for the second anchor
The field and `Save` button will be disabled.
The content of the field will be taken from the 'conflicting' variable.
![scale-apps--incompatible](/uploads/e8c5362bbc586514fde6efee53ce3a9b/scale-apps--incompatible.png)12.0Accepting merge requestsConfigureDeliverableGitLab PremiumProduct Vision 2018UXapplication control panelauto devopsbackenddevopsdevops:configuredirectionfeature proposalfrontend