### Problem to solve Currently, users of a project-level cluster can see deployments made to their cluster via the *Operations>>Environments* page. However, a cluster administrator who configures a group/instance level cluster cannot see what's deployed to the cluster unless they check the "environments" page project by project. ### Intended users Operators ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> ### Proposal 1. List "Kubernetes Deployments" made to the cluster(s) attached to the group. 1. List deployments with direction and indirect relationship to the group, ie. deployments from sub-groups will also show up on the list 1. Provide a link to the project's env page where more detail about the deployment can be found The operator is less concerned about "what" is being deployed and more with the usage of the resources in the cluster, for example: * number of deployments * pods used for particular deployments (follow up issue) * total pods being used in cluster (follow up issue) Provide an Operations>>K8S Deployments option, once clicked on it, user can see a list of projects that have deployed to this cluster. To make it lightweight we don't have to get full details of all deployments, simply a list of ALL deployments and then fetch information for each as user drills down. | Project | Deployment | Environment | Cluster | | ------ | ------ | ------ | ------ | | Minimal Ruby App | `#13 by user` | staging | mra-staging | | Minimal Ruby App | `#16 by user` | production | mra-production | ### Permissions and Security The same user-type who can see the "Kubernetes" menu currently should be able to see the "environments" page. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? TBD ### Links / references