GitLab.org issueshttps://gitlab.com/groups/gitlab-org/-/issues2024-02-14T09:03:14Zhttps://gitlab.com/gitlab-org/quality/triage-ops/-/issues/45Skip adding ~"missed\-deliverable" for confidential issues2024-02-14T09:03:14ZLin Jen-ShinSkip adding ~"missed\-deliverable" for confidential issuesThis is raised in https://gitlab.com/gitlab-org/gitlab-ee/issues/6881#note_100022144
Confidential issues might follow a different delivery approach and we might want to use a different way to assess how to count ~"missed\-deliverable"This is raised in https://gitlab.com/gitlab-org/gitlab-ee/issues/6881#note_100022144
Confidential issues might follow a different delivery approach and we might want to use a different way to assess how to count ~"missed\-deliverable"11.4Lin Jen-ShinLin Jen-Shinhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/45965Instance configuration and docs.gitlab.com settings pages do not match2024-02-14T01:03:30ZElliott Sales de AndradeInstance configuration and docs.gitlab.com settings pages do not matchThe information on the [instance configuration page](https://gitlab.com/help/instance_configuration) and the [docs.gitlab.com settings page](https://docs.gitlab.com/ee/user/gitlab_com/index.html) seem to differ. Some things look correct ...The information on the [instance configuration page](https://gitlab.com/help/instance_configuration) and the [docs.gitlab.com settings page](https://docs.gitlab.com/ee/user/gitlab_com/index.html) seem to differ. Some things look correct on one, but not the other:
1. On the instance page, the SSH host keys don't seem to match what I get with ssh-keyscan, but the docs.gitlab.com page matches.
1. The IP address for `gitlab.io` seems correct on the instance page, but the docs.gitlab.com page is different.
1. GitLab CI limits are different.
Also, if you're at the top-level ([help](https://gitlab.com/help/) or [docs.gitlab.com](https://docs.gitlab.com/ee/README.html)), there's a direct link to these pages from the 'help' site, but not from the 'docs.gitlab.com' site.11.4Tiago BotelhoTiago Botelhohttps://gitlab.com/gitlab-org/gitlab-qa/-/issues/323AutoDevOps QA spec may be failing prematurely2024-02-08T09:08:47ZStan HuAutoDevOps QA spec may be failing prematurelyIn https://gitlab.com/gitlab-org/gitlab-qa/-/jobs/95936449, the job fails:
```
Executing `gcloud container clusters delete --zone us-central1-a qa-cluster-3e149cbc-20180909004458 --quiet --async `
user creates a new project and runs...In https://gitlab.com/gitlab-org/gitlab-qa/-/jobs/95936449, the job fails:
```
Executing `gcloud container clusters delete --zone us-central1-a qa-cluster-3e149cbc-20180909004458 --quiet --async `
user creates a new project and runs auto devops (FAILED - 1)
HTML screenshot: file:///home/qa/tmp/qa-test-2018-09-09-00-41-49/browser_ui/7_configure/auto_devops/create_project_with_auto_devops_spec.rb_2018-09-09-01-13-20.314.html
Image screenshot: file:///home/qa/tmp/qa-test-2018-09-09-00-41-49/browser_ui/7_configure/auto_devops/create_project_with_auto_devops_spec.rb_2018-09-09-01-13-20.314.png
Failures:
1) configure Auto DevOps support user creates a new project and runs auto devops
Failure/Error: expect(pipeline).to have_build('production', status: :success, wait: 1200)
expected #has_build?("production", {:status=>:success, :wait=>1200}) to return true, got false
# ./qa/specs/features/browser_ui/7_configure/auto_devops/create_project_with_auto_devops_spec.rb:63:in `block (4 levels) in <module:QA>'
# ./qa/scenario/actable.rb:14:in `perform'
# ./qa/specs/features/browser_ui/7_configure/auto_devops/create_project_with_auto_devops_spec.rb:60:in `block (3 levels) in <module:QA>'
# ./qa/specs/runner.rb:28:in `perform'
# ./qa/scenario/template.rb:8:in `block in perform'
# ./qa/scenario/template.rb:6:in `tap'
# ./qa/scenario/template.rb:6:in `perform'
# ./qa/scenario/template.rb:29:in `perform'
# ./qa/scenario/template.rb:8:in `block in perform'
# ./qa/scenario/template.rb:6:in `tap'
# ./qa/scenario/template.rb:6:in `perform'
# ./qa/scenario/bootable.rb:14:in `launch!'
```
This is the screenshot from the failure:
![image](/uploads/284e4a347866017af0806d3c03ac4153/image.png)
Is it just that the build took longer than 1200 seconds?
/cc: @rymai11.4Mayra CabreraMayra Cabrerahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/29398Support Kubernetes RBAC for GitLab Managed Apps2024-02-08T07:12:39ZMark PundsackSupport Kubernetes RBAC for GitLab Managed Apps**Note**: we are forcing ABAC to be on when creating a new GKE cluster in **CI/CD > Kubernetes**, but we should revert this change when we'll have proper RBAC support, or at least auto-detect what we want to use based on the cluster.
##...**Note**: we are forcing ABAC to be on when creating a new GKE cluster in **CI/CD > Kubernetes**, but we should revert this change when we'll have proper RBAC support, or at least auto-detect what we want to use based on the cluster.
### Description
Kubernetes clusters support both Legacy authorization (ABAC) and full RBAC. We consider ABAC to be always enabled, and leverage this to install applications and to interact with the cluster.
Now that RBAC is enabled by default, and ABAC has been disabled by default on GKE, we want to support the new model.
### Proposal
Implement support for RBAC authorization for the apps we install to Kubernetes from the clusters page.
1. Enable RBAC by default on cluster creation.
* Once we confirm RBAC is enabled, create cluster-wide access roles for Helm Tiller
* Enable mutual TLS authentication for Tiller, with only GitLab having the private key. This will mitigate to a large degree the huge security hole we create * above with Tiller having cluster-wide access.
* For all GitLab managed apps, enable RBAC role creation based on their helm chart settings.
2. Restrict tiller to GitLab managed apps in the configured namespace
3. Provide apps read access outside the namespace (if not provided by default)
~~The first iteration should support project isolation: it means that, if a cluster is used by different projects at the same time, a project cannot alter applications for other projects.~~
~~Instead of using the global admin credentials to interact with the cluster, we should:~~
1. ~~store the admin credentials in a safe place, without exposing them to pipelines~~
1. ~~create project-specific credentials and expose them to pipelines~~
1. ~~authorize changes only to the namespace associated to that project (must be unique)~~
1. check that helper applications (tiller, ingress, etc) are still working as expected
### Feature flag
Since we are are not planning to ship auto devops RBAC in 11.3, the plan is to provide RBAC support for GitLab Managed apps behind a feature flag. When the user/admin enables the "experimental RBAC support" feature flag (auto devops and web terminal support coming soon), then the front-end form will now include a check-box "RBAC-enabled cluster".
### Links / references
- https://kubernetes.io/docs/admin/authorization/rbac/
- https://kubernetes.io/docs/admin/authorization/abac/
- https://docs.helm.sh/using_helm/#role-based-access-control
- https://docs.helm.sh/using_helm/#securing-your-helm-installation
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->11.4Dimitrie HoekstraTaurie DavisThong Kuahtkuah@gitlab.comDimitrie Hoekstrahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/45912Jupyter runbooks2024-02-08T07:09:46ZJoshua LambertJupyter runbooksCompanies are beginning to consider using interactive notebooks, such as Jupyter notebooks, for DevOps/SRE work. Instead of a markdown/text runbook, consider a fully interactive runbook with support for pulling in metrics as well as an i...Companies are beginning to consider using interactive notebooks, such as Jupyter notebooks, for DevOps/SRE work. Instead of a markdown/text runbook, consider a fully interactive runbook with support for pulling in metrics as well as an integrated "command line" tool to take action.
Other companies already have a metrics notebook, such as [Azure](https://docs.microsoft.com/en-us/azure/application-insights/app-insights-usage-workbooks) and [DataDog](https://docs.datadoghq.com/graphing/notebooks/) but are any additional integrations.
Consider this prior art: https://www.nurtch.com/
### Proposal
We already have, or are working on, many of the potential components:
* ChatOps
* Similarly, an interface for executing ChatOps commands outside of Slack. Effectively your CLI, or you can bring your own as well.
* Metrics integration with Prometheus.
* We should provide a simple tool to explore the integrated Prometheus data from Jupyter notebooks.
* This could route through GitLab to provide k8s proxy capabilities, so the notebook doesn't have to have direct access to the Prometheus server.
* Tracing, Logs
* We should also incorporate the ability to pull in tracing and logging data, similarly to Metrics
* Merge Request/Issues/Commits
* It would be nice to clearly refer to problematic commits, diffs in MR's, etc.
With the integration of Notebooks into GitLab, this could be an extremely powerful interactive tool.11.4https://gitlab.com/gitlab-org/gitlab-foss/-/issues/48004Support PostgreSQL DB migration and initialization for Auto DevOps2024-02-08T07:08:52ZMark PundsackSupport PostgreSQL DB migration and initialization for Auto DevOps### Problem to solve
Apps need to have databases configured before they work, and migrations run when they're updated. Auto DevOps doesn't currently support methods to initialize or migrate databases.
### Further details
When apps are...### Problem to solve
Apps need to have databases configured before they work, and migrations run when they're updated. Auto DevOps doesn't currently support methods to initialize or migrate databases.
### Further details
When apps are first deployed, they sometimes need a database to be initialized before they'll even start running.
When apps are updated and migrations are needed, they'll sometimes fail until the migrations are performed
### Proposal
**Option 1**
Implement support for db initilization and migration for auto devops.
*On initialize:*
* Create post install hook
* initialize
* restart app
*On migration:*
* Create pre-upgrade hook
* run migration
*Pseudocode:*
- if `$DB_INITIALIZE`
- Create post-install hook:
- run `$DB_INITIALIZE`
- restart app pods
- if `$DB_MIGRATE`
- Create pre-upgrade hook:
- run `$DB_MIGRATE`
**Option 2**
Split up the helm chart into a db chart and an app chart. This allows for separate deployment of db with a post-install hook to initialize. Application can then be started after db in configured.
**Option 3**
User kubernetes [custom controllers](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (operators) to do this outside of helm. There seem to be already some [existing postgres operators](https://github.com/zalando-incubator/postgres-operator) that could be leveraged.
### 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)
### Notes/Questions
* How can we know how to run database commands for every language? Some buildpacks have this built in, but some don't (notably Ruby/Rails buildpack). Ideally we'd just rely on Herokuish to configure this for us, but it doesn't work.
Even if we have good defaults, some teams may need to customize their database initialization and migration commands.
* Keep env variables generic (ie `$initialize`, `$pre_deploy`, `$post_deploy`
### Links / references
* [Helm hooks](https://github.com/helm/helm/blob/master/docs/charts_hooks.md)
* Heroku [Release Phase](https://blog.heroku.com/announcing-release-phase-run-tasks-before-new-release-deployed)
* https://gitlab.com/gitlab-org/gitlab-ce/issues/33520
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->11.4Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/48399Skip auto devops jobs based on license2024-02-08T07:08:41ZDaniel GruessoSkip auto devops jobs based on license### Problem to solve
Currently, certain auto devops jobs do not run if user is on CE instance (ie SAST, dependency scanning) however we continue to show those jobs in the pipeline view of auto devops. Additionally, we currently run jobs...### Problem to solve
Currently, certain auto devops jobs do not run if user is on CE instance (ie SAST, dependency scanning) however we continue to show those jobs in the pipeline view of auto devops. Additionally, we currently run jobs that may not apply to the GitLab instance running them (based on license).
### Further details
Use cases:
1. Do not run Auto SAST jobs unless license = ultimate
2. Do not run Auto Container Scanning unless license = ultimate
3. Do not run Auto DAST jobs unless license = ultimate
4. Do not run Auto Browser Performance Testing unless license = premium
### Proposal
1. Use `$GITLAB_FEATURES` and regex logic to determine which jobs to run
2. If instance does not have the right license, skip all jobs that do not apply for that license
3. Do not show skipped jobs in the pipeline view of auto devops
Additionally, it may be useful to indicate to the user:
* which jobs did not run
* why they didn't run
* how they can upgrade in order to run those jobs
### What does success look like, and how can we measure that?
Cleaner pipeline view for auto devops jobs (less failed jobs) for relevant licenses.
### Links / references
### Solution
this work will only involve changing the [Auto DevOps CI template](https://gitlab.com/gitlab-org/gitlab-ce/blob/41729-enable-auto-devops-instance-wide-for-everyone/vendor/gitlab-ci-yml/Auto-DevOps.gitlab-ci.yml) to make use of [only/except](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex) and therefore will behave the same as any customer created CI YML file that uses `only/except`.
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*
<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->11.4https://gitlab.com/gitlab-org/gitlab-foss/-/issues/48418Design Artifact: Group-level Kubernetes page2024-02-08T07:08:39ZDaniel GruessoDesign Artifact: Group-level Kubernetes page### Description
At project level, we have **CI/CD > Cluster** page to create (and then use) a cluster on GKE. This page will be extended further to support more functions.
It is still impossible to define the same cluster for different...### Description
At project level, we have **CI/CD > Cluster** page to create (and then use) a cluster on GKE. This page will be extended further to support more functions.
It is still impossible to define the same cluster for different projects in the same group, but this could be a very important feature for organizations that can set up a single cluster and make it available group-wide.
### Proposal
Add a **CI/CD > Cluster** page at group level, that is similar to the project level one.
But there are questions that should be considered:
- project namespace must be unique in the cluster, so it still should be specified at project level
- enable/disable the cluster integration will enable/disable the access to projects?
- how to show the availability of the group-level cluster at project level?
- security implications of different projects on the same cluster
Matching delivery issue https://gitlab.com/gitlab-org/gitlab-ce/issues/3475811.4Taurie DavisThong Kuahtkuah@gitlab.comTaurie Davishttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/49820Document how to enable auto devops at the instance level2024-02-07T17:44:43ZDaniel GruessoDocument how to enable auto devops at the instance level### Problem to solve
Currently, we document how to enable auto devops at the project-level but we do not offer documentation on how to enable it at the instance-level.
### Proposal
Expand https://docs.gitlab.com/ee/topics/autodevops/#...### Problem to solve
Currently, we document how to enable auto devops at the project-level but we do not offer documentation on how to enable it at the instance-level.
### Proposal
Expand https://docs.gitlab.com/ee/topics/autodevops/#enabling-auto-devops to include instructions on how to enable auto devops at the instance level.11.4Achilleas PipinellisAchilleas Pipinellishttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/50111Improve design of cluster apps to handle larger quantity2024-02-07T17:44:28ZJoshua LambertImprove design of cluster apps to handle larger quantityWhen we initially got started with the cluster app deployment page, we didn't have that many: Runner, Ingress, Prometheus, Tiller.
As we continue to integrate with additional apps, the list is starting to grow unwieldy. Current state:
!...When we initially got started with the cluster app deployment page, we didn't have that many: Runner, Ingress, Prometheus, Tiller.
As we continue to integrate with additional apps, the list is starting to grow unwieldy. Current state:
![Screen_Shot_2018-08-08_at_10.46.59_AM](/uploads/8d6d74e5a24bb5ac8d38ebbff38cd111/Screen_Shot_2018-08-08_at_10.46.59_AM.png)
A few apps we have on deck that we know we will have to add soon:
* `cert-manager` for easy HTTPS
* Istio for service mesh support: https://gitlab.com/gitlab-org/gitlab-ee/issues/3633
* Elasticsearch: https://gitlab.com/gitlab-org/gitlab-ee/issues/5694
* Jaeger: https://gitlab.com/gitlab-org/gitlab-ee/issues/5182
* Meltano: https://gitlab.com/meltano/meltano
### Design
- When Helm Tiller is not installed, the rest applications grey out, and there is a message tells users that they need to install Helm Tiller first.
- If the applications are failed to install, it will show the the error message and the button will change to `Try again`.
- SVG: `kubernetes-installation.svg` in gitlab-svgs
| Helm Tiller is **not** installed | Helm Tiller has been installed | Error |
| --- | --- | --- |
| ![image](/uploads/c45adbf8f330679f205495f0e8243f57/image.png) | ![image](/uploads/f4a56dc352cd3a4e12b8eb5fbb6f5f4f/image.png) | ![image](/uploads/1b89d9f7902e3110d9a6d7a6f1d8198d/image.png) |
#### logo images
![elasticsearch](/uploads/1016f14feab51a589b7dbb92ac1e4948/elasticsearch.png)
![GitLab](/uploads/713b6cde5a798c64b84865f7420a2073/GitLab.png)
![jeager](/uploads/6fe626490537269d308c402da13b7b47/jeager.png)
![helm](/uploads/827a4f45ba07424b9c571934514a20c0/helm.png)
![jupyterhub](/uploads/999e5fd19c06bbb2ec275a390c6e98e4/jupyterhub.png)
![kubernetes](/uploads/ed8893a62dbe2be38b960ed10e3b2607/kubernetes.png)
![meltano](/uploads/09d6b4cb821da1cee64b529b4e6c23c4/meltano.png)
![prometheus](/uploads/5a76bd05721cc01d293a2f50ffd5eedd/prometheus.png)
Download here: [export_logos.zip](/uploads/954bc34bf7a6f3cd62170be2e1f549b9/export_logos.zip)11.4Dimitrie HoekstraTaurie DavisMike GreilingDimitrie Hoekstrahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/50186503 error when trying to open live environment using auto devops2024-02-07T17:44:20ZJerome Uy503 error when trying to open live environment using auto devops### Summary
A user setups an auto devops but a 503 error is encountered whenever the user opens a live environment. Angular CLI is being used to create the project.
### Steps to reproduce
The issue is found in the Operations > Environ...### Summary
A user setups an auto devops but a 503 error is encountered whenever the user opens a live environment. Angular CLI is being used to create the project.
### Steps to reproduce
The issue is found in the Operations > Environment > (Open Live Environment) link.
### What is the current *bug* behavior?
503 error is being produced.
### Relevant logs and/or screenshots
Sentry Log Link: https://sentry.gitlap.com/gitlab/gitlabcom/issues/474445
ZD Ticket: https://gitlab.zendesk.com/agent/tickets/101466 (internal)11.4Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/7206Protected environments Metrics2024-02-07T17:44:20ZKamil TrzciĆskiProtected environments MetricsCurrently, [Protected environments](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6672) is hidden behind feature flag (`protected_environments`) due to some performance concerns of that feature: https://gitlab.com/gitlab-org/git...Currently, [Protected environments](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6672) is hidden behind feature flag (`protected_environments`) due to some performance concerns of that feature: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6672#note_92769659.
We will:
1. Deploy 11.3 to staging and gitlab.com,
2. Enable feature flag and monitor the impact of the feature on the performance of GitLab.com
3. If everything is OK, we have an open MR ready to be merged that removes the feature flag and makes the feature to be available. This should ideally be merged for 11.4 at the latest. (https://gitlab.com/gitlab-org/gitlab-ee/issues/7536)
Feature can be enabled on staging with
```
/chatops run feature set --staging protected_environments true
```
and on production with
```
/chatops run feature set protected_environments true
```
### Metrics to monitor
- https://dashboards.gitlab.net/d/000000120/rails-controllers?orgId=1&var-action=Projects::PipelinesController%23index.json&var-database=influxdb-01-inf-gprd
- https://dashboards.gitlab.net/d/000000120/rails-controllers?orgId=1&var-action=Projects::PipelinesController%23show.json&var-database=influxdb-01-inf-gprd
- https://dashboards.gitlab.net/d/000000120/rails-controllers?orgId=1&var-action=Projects::PipelinesController%23stage.json&var-database=influxdb-01-inf-gprd
- https://dashboards.gitlab.net/d/000000120/rails-controllers?orgId=1&var-action=Projects::PipelinesController%23stage_ajax.json&var-database=influxdb-01-inf-gprd
- https://dashboards.gitlab.net/d/000000126/grape-endpoints?orgId=1&var-action=Grape%23POST%20%2Fapi%2Fjobs%2Frequest&var-database=influxdb-01-inf-gprd
### Plan
* [x] Enable feature on Sept 5 at 19:00 pm UTC for 1 hour. Confirm it didn't occur any problems/performance degradation
* [x] Enable feature on from Sept 6, 15:00pm to Sept 7, 15:00pm UTC. Confirm it didn't occur any problems/performance degradation
* [x] Enable feature on from Sept 10, 20:00pm to Sept 14, 20:00pm UTC. Confirm it didn't occur any problems/performance degradation
* [x] If no problem arises, enable feature permanently11.4Mayra CabreraMayra Cabrerahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/50289Un-vendor CI templates2024-02-07T17:44:16ZDylan Griffithdgriffith@gitlab.comUn-vendor CI templatesPer discussions in https://gitlab.com/gitlab-org/gitlab-ce/issues/42265 we agreed that the best thing to do here is to no longer store our templates in the https://gitlab.com/gitlab-org/gitlab-ci-yml repo
As such we should instead just ...Per discussions in https://gitlab.com/gitlab-org/gitlab-ce/issues/42265 we agreed that the best thing to do here is to no longer store our templates in the https://gitlab.com/gitlab-org/gitlab-ci-yml repo
As such we should instead just pull them into our repo and manage them there.
This requires a few steps:
- [x] Move the files from the `vendor/` directory to somewhere else in `gitlab-ce` since this word `vendor` no longer conveys the right meaning anymore
- [x] Ensure the tests we were running in https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/verify_templates.rb are still covered in `gitlab-ce` (but now they're simpler because we just use the parser code in `gitlab-ce` rather than calling the API)
- [x] Ensure we've copied the latest files for everything from https://gitlab.com/gitlab-org/gitlab-ci-yml
- [x] Deprecate `gitlab-org/gitlab-ci-yml` and update README to point to the new home of these files
- [x] Archive https://gitlab.com/gitlab-org/gitlab-ci-yml11.4Dylan Griffithdgriffith@gitlab.comDylan Griffithdgriffith@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/7412Product Discovery for Group-Level K8S Cluster Configuration2024-02-07T17:44:01ZDaniel GruessoProduct Discovery for Group-Level K8S Cluster Configuration## Background:
Currently K8S clusters can only be configured at the project level. If the same cluster is being used for multiple projects, it must be manually added multiple times.
We want provide users the ability to do [Group-level ...## Background:
Currently K8S clusters can only be configured at the project level. If the same cluster is being used for multiple projects, it must be manually added multiple times.
We want provide users the ability to do [Group-level K8S cluster config](https://gitlab.com/gitlab-org/gitlab-ce/issues/34758) so a single cluster can be shared across projects.
**What questions are you trying to answer?**
What is the smallest sequence of mergeable steps that can be done for this?
See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21831#possible-mrs (:warning: WIP)
**Are you looking to verify an existing hypothesis or uncover new issues you should be exploring?**
No existing hypothesis
**What is the backstory of this project and how does it impact the approach?**
GitLab has provided the ability to connect a K8S cluster since 10.1, however, it has always taken place at the project level. This does not allow organization that use clusters at a group or org level to define a cluster once and use it across the entire org. We want the user to be able to easily define *at which level they want to configure this cluster*.
**What do you already know about the areas you are exploring?**
**What does success look like at the end of the project?**
Technical discovery for this issue should inform the MVC for the implementation issue.
## Decisions
* We will only install group-level cluster applications in group clusters - https://gitlab.com/gitlab-org/gitlab-ce/issues/48418#note_103788885 (projects install cluster apps into group clusters should be a *new issue*)
* We will ship without Prometheus in the first release - https://gitlab.com/gitlab-org/gitlab-ee/issues/7412#note_103921412
* We will ship with nginx-ingress configured to watch cluster-wide. (no change from project-level nginx-ingress) - https://gitlab.com/gitlab-org/gitlab-ce/issues/48418#note_103773744
* We will ship without Jupytyerhub and Runner in the first release
* Group-level cluster will follow the same licensing approach as project-level clusters: CE will allow for 1 cluster at the group level (or sub-group level) and EE will allow for multiple cluster configuration (first iteration is likely to include single cluster capability). For example, on CE, Group 1 and sub-group A can each have 1 cluster only, on EE multiple cluster are supported.
* For CE, having a cluster configured at the group level shall not affect the ability for related project to have project-level clusters setup, that is, if Group 1 has a cluster setup, project 1A can have a separate cluster setup (project 1A belonging to Group 1).
* Group cluster would be available to projects under their namespace. - https://gitlab.com/gitlab-org/gitlab-ee/issues/7412#note_104034851
## User stories and mockups
### Sidebar and empty state
|EE/CE|
|--|
|As an owner or maintainer, I should see a `Kubernetes` tab in my group sidebar.|
|As an owner or maintainer, I should see an empty state with a call to action when I have no group clusters.|
|![group__operations--kubernetes-empty-state](/uploads/df68d89c79ba537eb582a5135808a7d6/group__operations--kubernetes-empty-state.png)|
### Environment scope
|EE|CE|
|--|--|
|As an owner or maintainer, I can set the environment scope when creating my group cluster.|As an owner or maintainer, I cannot set the environment scope when creating my group cluster. The environment scope is `*`.|
|![EE-group__operations--kubernetes-create](/uploads/6d78f340fcdc3d8d8a4038f90477e083/EE-group__operations--kubernetes-create.png)|![CE-group__operations--kubernetes-create](/uploads/e0c09aeac3694bc1414990be9f1b6b85/CE-group__operations--kubernetes-create.png)|
### Applications and domain
|EE/CE|
|--|
|As an owner or maintainer, I am able to install Helm Tiller and Ingress on my group level cluster. **Note:** The only difference between EE/CE mockups would be the ability to set an environment.|
|As an owner or maintainer, I am able to set a domain for both my group and project level clusters.|
|Group|Project|
|--|--|
|![CE-group__operations--kubernetes-domain-applications](/uploads/f9eeac1f16b6ba382943db0bc12828b2/CE-group__operations--kubernetes-domain-applications.png) Helm and Ingress not installed, domain disabled|![CE-project__operations--kubernetes-domain-applications](/uploads/bb7c601c871fd05044ffe10bf6485f63/CE-project__operations--kubernetes-domain-applications.png) Helm and Ingress not installed, domain disabled|
|![CE-group__operations--kubernetes-domain-applications-installed](/uploads/471d55280d44b92cc21e557ac33e9123/CE-group__operations--kubernetes-domain-applications-installed.png) Helm and Ingress installed, domain enabled|![CE-project__operations--kubernetes-domain-applications-installed](/uploads/3b42c33b20e10fdc10dd82ff6c1b6b83/CE-project__operations--kubernetes-domain-applications-installed.png) Helm and Ingress installed, domain enabled|
**Improvements:** Alternative issues will be made for installing GitLab Runner, Prometheus, and Jupyterhub https://gitlab.com/groups/gitlab-org/-/epics/114
### Group clusters
|EE|CE|
|--|--|
|As an owner or maintainer, I am able to add multiple group clusters to each group or subgroup.|As an owner or maintainer, I can only add one group cluster to each group or subgroup.|
|![EE-group__operations--kubernetes-one-project](/uploads/2b3910438a1357c1b48199f0698ae97a/EE-group__operations--kubernetes-one-project.png) Add cluster button enabled|![CE-group__operations--kubernetes-one-project](/uploads/5e6f7d38e6d334989ed448209ca4d321/CE-group__operations--kubernetes-one-project.png) Add cluster button disabled|
|EE/CE|
|--|
|Group level clusters will be automatically added to projects within that group.|
### Cluster Overrides
|CE|
|--|
|As a user who created a new group cluster, I will be warned if my cluster won't be active for any given project.|
|![CE-group__operations--kubernetes-warning](/uploads/18970bea64388f001fffd6f8e4a1c3ef/CE-group__operations--kubernetes-warning.png)|
**Improvement:** Allow users to specify which projects they would like override. *Create new issue*
|EE|CE|
|--|--|
|As an owner or maintainer, I can have multiple active cluster integrations at various levels on my project.|As an owner or maintainer, I can only have one active cluster integration on my project.|
|![EE-project__operations--kubernetes-two](/uploads/7c3b434a6a7f6e0ad60a93c8549c4f47/EE-project__operations--kubernetes-two.png)|![CE-project__operations--kubernetes-two](/uploads/527050ec2f590e9a50946f6f8fd161a1/CE-project__operations--kubernetes-two.png)|
|![EE-project__operations--kubernetes-four-2](/uploads/32504a27222bc94b51fd772cd24084ce/EE-project__operations--kubernetes-four-2.png)|![CE-project__operations--kubernetes-four](/uploads/f54ec933df865e74a24642bac8fa3053/CE-project__operations--kubernetes-four.png)|
|EE|
|--|
|If multiple clusters exist at the same level, my environment will first look for an exact match, then a partial match, then `*`|
|If there are multiple matches, my environment will choose the first match. Project -> Subgroup -> Group|
|![EE-project__operations--kubernetes-four-1](/uploads/ea8ebede73a77d8e248134850559534d/EE-project__operations--kubernetes-four-1.png)|
|If my environment has no match, it will continue up the chain to find a match. Project -> Subgroup -> Group|
|CE|
|--|
As an owner or maintainer, I have the ability to add one project level cluster even if there are group clusters. This will override my group level integration for this project.|
|![CE-project__operations--kubernetes-one-group](/uploads/d30f765c35163d43052ff8954c32662e/CE-project__operations--kubernetes-one-group.png) Add cluster button enabled|
|![CE-project__operations--kubernetes-override-integration](/uploads/d485a93a6208b024e95be33edd9b5ee6/CE-project__operations--kubernetes-override-integration.png)|
**Possible improvement:** Explore always keeping the create button enabled. In CE, this would mean owners and maintainers can add as many integrations as they want, but they must select one: either a group or a project level cluster. This removes confusion over why the user cannot create another integration. *Create new issue*
### Editing group clusters
|EE/CE|
|--|
|As an owner or maintainer, I can view a group cluster on my project. The cluster links to the group cluster page, and I must make any edits there.|
|As an owner or maintainer, I cannot remove a group level cluster from a specific project. I can only override the cluster with a project cluster.|
|![CE-project__operations--kubernetes-one-group](/uploads/d30f765c35163d43052ff8954c32662e/CE-project__operations--kubernetes-one-group.png)|
**Improvement:** Allow users to exclude a group level cluster from a specific project. *Create new issue*
### Auto DevOps project settings
|EE/CE|
|--|
|As an owner or maintainer, I am no longer able to set a domain within my project Auto DevOps settings|
|![CE-project__settings--ci-cd-autodevops](/uploads/957416e9f26b785f5cdd9082444e3ec9/CE-project__settings--ci-cd-autodevops.png)|
**Improvement:** Resolve any UX Debt around deployment strategy, especially after moving the domain to cluster settings. *Create new issue*
## Links / references:
Implementation issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/3475811.4Taurie DavisThong Kuahtkuah@gitlab.comTaurie Davishttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51009Remove rbac_clusters feature flag2024-02-07T17:44:00ZThong Kuahtkuah@gitlab.comRemove rbac_clusters feature flagThe `rbac_clusters` feature flag was introduced in !21127 and should be removed once https://gitlab.com/gitlab-org/gitlab-ce/issues/44597 is complete. (or https://gitlab.com/gitlab-org/gitlab-ce/issues/51942 is complete)
See also https:...The `rbac_clusters` feature flag was introduced in !21127 and should be removed once https://gitlab.com/gitlab-org/gitlab-ce/issues/44597 is complete. (or https://gitlab.com/gitlab-org/gitlab-ce/issues/51942 is complete)
See also https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21127#note_98722913
## Proposal
* Remove `rbac_clusters` feature flag
* Default to RBAC clusters enabled, both on the "create new cluster" and "add existing cluster" case
* Adjust QA to match, possibly remove `--enable-legacy-authorization` from Kubernetes tests. https://gitlab.com/gitlab-org/gitlab-ce/-/jobs/103932302
* Update documentation
## Solution
* Remove `rbac_clusters` feature flag
* Leave RBAC cluster **disabled** as security model for RBAC is not ideal
* Update documentation (remove bit about toggling Feature Flag)
* Add QA for adding/creating RBAC clusters - https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22025
## Manual QA
**Staging**
* [x] Enable RBAC
* [x] Check "Create new cluster" scenario
* [x] Create cluster
* [x] Install all the applications
* [x] Check "Add an existing RBAC cluster" scenario
* [x] Create cluster
* [x] Install all the applications
**Production**
* [x] Wait for an 11.4 RC to land on production
* [x] Enable RBAC
* [x] Check "Create new cluster" scenario
* [x] Create cluster
* [x] Install all the applications
* [x] Check "Add an existing RBAC cluster" scenario
* [x] Create cluster
* [x] Install all the applications11.4Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab/-/issues/7536Removes feature flag code for Protected Environments2024-02-07T17:43:50ZMayra CabreraRemoves feature flag code for Protected EnvironmentsAfter https://gitlab.com/gitlab-org/gitlab-ee/issues/7206, we need to remove the feature flag code surrounding the protected environments feature.After https://gitlab.com/gitlab-org/gitlab-ee/issues/7206, we need to remove the feature flag code surrounding the protected environments feature.11.4Mayra CabreraMayra Cabrerahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51450Auto-DevOps.gitlab-ci.yml: Vendor in refactoring to registry login2024-02-07T17:43:44ZThong Kuahtkuah@gitlab.comAuto-DevOps.gitlab-ci.yml: Vendor in refactoring to registry loginVendor in https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/193Vendor in https://gitlab.com/gitlab-org/gitlab-ci-yml/merge_requests/19311.4Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/51942Use local tiller - Auto DevOps2024-02-07T17:43:29ZThong Kuahtkuah@gitlab.comUse local tiller - Auto DevOpsThis probably replaces [one of the issues](https://gitlab.com/gitlab-org/gitlab-ci-yml/issues/82) for enabling RBAC for Auto Devops.
https://gitlab.com/gitlab-org/gitlab-ci-yml/issues/82#note_104395604
Is it possible to run tiller loca...This probably replaces [one of the issues](https://gitlab.com/gitlab-org/gitlab-ci-yml/issues/82) for enabling RBAC for Auto Devops.
https://gitlab.com/gitlab-org/gitlab-ci-yml/issues/82#note_104395604
Is it possible to run tiller locally:
- download tiller binary
- Replace `helm init` with starting tiller locally as a daemon (https://github.com/adamreese/helm-local)
- Run helm commands as usual
Advantages :
- no need to send `$KUBE_SERVICE_ACCOUNT`
- no more `tiller-deploy` pod that we have to add TLS, etc
resources: https://github.com/helm/helm/pull/444311.4Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.comhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/52116Add a QA spec for RBAC cluster and auto devops2024-02-07T17:43:19ZMayra CabreraAdd a QA spec for RBAC cluster and auto devops### Problem to solve
Currently, QA does not include a spec for running ADO pipeline on RBAC cluster
Second step of [Meta: Auto DevOps support for RBAC
](https://gitlab.com/gitlab-org/gitlab-ce/issues/44597)
### Proposal
Add a QA spec...### Problem to solve
Currently, QA does not include a spec for running ADO pipeline on RBAC cluster
Second step of [Meta: Auto DevOps support for RBAC
](https://gitlab.com/gitlab-org/gitlab-ce/issues/44597)
### Proposal
Add a QA spec that ensures support of AutoDevOps on RBAC cluster11.4Mayra CabreraMayra Cabrerahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/52143Auto DevOps : Use local tiller directly2024-02-07T17:43:16ZThong Kuahtkuah@gitlab.comAuto DevOps : Use local tiller directlyUse `tiller` directly vs performing a network call to download a helm plugin
Continuation from https://gitlab.com/gitlab-org/gitlab-ce/issues/51942 where we switched to local tiller in Auto-DevOps.gitlab-ci.ymlUse `tiller` directly vs performing a network call to download a helm plugin
Continuation from https://gitlab.com/gitlab-org/gitlab-ce/issues/51942 where we switched to local tiller in Auto-DevOps.gitlab-ci.yml11.4Thong Kuahtkuah@gitlab.comThong Kuahtkuah@gitlab.com