cloudoperators / greenhouse Goto Github PK
View Code? Open in Web Editor NEWCloud operations platform
License: Apache License 2.0
Cloud operations platform
License: Apache License 2.0
A violation against the OSS Rules of Play has been detected.
Rule ID: rl-reuse_tool-3
Explanation: Is it registered in REUSE? No
Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html
Umbrella issue for tracking the OCM evaluation.
Granular sub-issues can be found via label WP2.3.4.5 OCM evaluation
.
Evaluate OCM integration in Greenhouse as an addition or replacement of the Helm controller logic aiming to achieve a unified specification and management of software of the ORA stack.
As noted down in the internal repository by @IvoGoman:
With the current implementation all Plugins will be installed into the Greenhouse managed namespace within the remote clusters.
In order to have a more granular setup and to avoid a "mono-namespace" it should be possible to provide a namespace with the PluginConfig. To ensure that no helm releases are left-behind this namespace should be immutable and defaulted to the Greenhouse managed namespace.
(Low) Something is a little off
In order to ensure no objects are left behind there should be a garbage collection that removes all Greenhouse managed resources from the managed cluster.
Under normal circumstances the Greenhouse Controller will ensure that their managed CRDs are removed during the Lifecycle.
Acceptance criteria:
No response
(Medium) I'm annoyed but I'll live
The service-proxy
allows to expose Kubernetes Service resources from an onboarded cluster. In the past this has caused troubles if the combined $service-$namespace-$cluster
is longer than 63 characters.
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
RFC1035
From an initial discussion with @databus23 this solution is proposed:
With some proposals for the generated name:
No response
Umbrella issue for tracking e2e test framework efforts.
Granular sub-issues can be found via label WP2.3.4.6 End-to-end test framwork
.
Greenhouse should have an e2e test framework to ensure the stability and reliability of our platform.
Acceptance criteria:
(Medium) I'm annoyed but I'll live
Helm supports a limited amount of Kubernetes Versions:
As of Helm 3, Helm is assumed to be compatible with n-3 versions of Kubernetes it was compiled against
[1] Helm Version skew
This matches the Kubernetes versions officially supported [2] Kubernetes Supported Versions
The Greenhouse HelmController should supported the officially supported Kubernetes Versions by Kubernetes & Helm but not more.
Acceptance Criteria:
No response
None
Currently it is possible for a Greenhouse Admin to delete a PluginDefinition, for which there are existing Plugins. The reconciliation of these Plugins will fail since the Webhook denies admission of Plugins referencing non-existing PluginDefinitions.
Acceptance Criteria:
PluginDefinition
exist1. Delete any PluginDefinition
2. Plugins cannot be reconciled, as the referenced PluginDefinition is missing.
(Low) Something is a little off
The Team and TeamMemberShip CRDs enable user management within an Organization.
Currently, all Teams are being considered by any Plugin regardless of the Plugins relevance for a Team.
Granular control is needed.
Proposal:
greenhouse.sap/supernova
to Teams
greenhouse.sap/support-group
No response
(Medium) I'm annoyed but I'll live
Plugins can have other Plugins as pre-requisites or dependencies. It can be the case that one plugin requires that another one is deployed and/or that they are requiring the partially the same configuration. In these cases the configuration has to be maintained for each Plugin.
In order to reduce the configuration effort on the Plugins themselves, it should be possible to integrate Plugins with each other.
E.g. logshipper Plugin to allow collection and forwarding of container logs. logs backend that provides an OpenSearch cluster or maybe just the connection details to an existing cluster. It should be possible to take the required connection configuration from a logs Plugin and make it available to the logshipper Plugin.
Currently we are handling this with a multitude of helm values files that make it possible to share this between helm charts. In the context of Plugins it would be an option to reference options from other plugins. For example PluginDefinitionA declares that it requires OptionB from a PluginDefintionB. This way during the configuration of the PluginA from the Greenhouse UI the value may be pre-populated from an existing PluginB that runs in the same target cluster.
Acceptance criteria:
No response
(Low) Something is a little off
Found the issue: go: cannot install cross-compiled binaries when GOBIN is set
There is an open issue already for that: golang/go#57485
Option's to mitigate the issue:
remove $GOBIN
add -o to the go install go build -o out ...
apiVersion: greenhouse.sap/v1alpha1
kind: ...
(Medium) I'm annoyed but I'll live
Currently the Team RBAC uses direct mapping of TeamRoleBinding to Cluster and Team by name.
It should be made possible to set a LabelSelector instead for either referenced resource. This will reduce the configuration effort for the ClusterAdmin and makes RBAC work OOTB for newly onboarded clusters and teams.
Acceptance Criteria:
No response
Implement a GitHub action to build the static Hugo documentation site and publish to GH pages.
Sources:
Umbrella issue for tracking the cluster registry feature in the roadmap 2023 Kanban board.
Granular sub-issues can be found via label WP2.3.4.4 Cluster registry
.
Manage operational tooling in registered Kubernetes cluster via Greenhouse.
Acceptance criteria:
(Low) Something is a little off
The login page provided by dex is not styled in the same way the rest of the Greenhouse UIs.
As a Greenhouse user, I want to easily identify what the Login page asks, so that I can access Greenhouse with the correct context.
It would be nice if we could have
Login to Greenhouse
instead of dex
No response
(Medium) I'm annoyed but I'll live
Currently, the TeamRole enables users to specify permissions using inclusivce Kubernetes RBAC policy rules.
To support the common use case to grant view-only permissions on most resources but exclude some (e.g. secrets) aggregation rules can be used instead of specifying the policy rules explicitly.
See the ClusterRole example:
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.authorization.k8s.io/aggregate-to-view: "true"
TODO:
(Medium) I'm annoyed but I'll live
As a ClusterAdmin, I want to configure common configuration once in a central place, so that all plugins requiring this configuration values get them automatically
In contrast to #84 this is not a 1:1 relationship between plugins but a central place where configuration can be maintained on a Organization or Cluster level.
Acceptance criteria:
work out a concept for sharing configuration between Plugins and document in an ADR
implement the solution
(Medium) I'm annoyed but I'll live
Definition based on:
Tasks:
Add New Plugin
button which would display the available plugins definition from the PR #142 in a panelIt seems that no plugins have been created yet. Do you want to create a new one?
with a button to the available plugins definition (panel) from the PR #142 when no plugins found.Plugin
deleteNo response
Umbrella issue for tracking Ceph integration.
Granular sub-issues can be found via label WP2.3.4.7 Ceph integration
.
Greenhouse must support operational tooling required by the upcoming Ceph implementation.
Coordinate efforts with @jknipper, @defo89, @SchwarzM.
Acceptance criteria:
This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.
These updates are currently rate-limited. Click on a checkbox below to force their creation now.
k8s.io/api
, k8s.io/apiextensions-apiserver
, k8s.io/apimachinery
, k8s.io/cli-runtime
, k8s.io/client-go
, k8s.io/component-base
, k8s.io/kubectl
)These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
@babel/core
, @babel/preset-env
, @babel/preset-react
, @babel/preset-typescript
, @types/node
, @types/react
, @types/react-dom
, autoprefixer
, eslint-plugin-react-hooks
, postcss
, sapcc-k8sclient
, tailwindcss
, zustand
)@babel/preset-react
, @babel/preset-typescript
, @tanstack/react-query
, @types/react
, @types/react-dom
, esbuild
, react
, react-dom
, react-test-renderer
, sass
, ts-luxon
, typescript
, zustand
)k8s.io/api
, k8s.io/apiextensions-apiserver
, k8s.io/apimachinery
, k8s.io/cli-runtime
, k8s.io/client-go
, k8s.io/component-base
, k8s.io/kubectl
, sigs.k8s.io/controller-runtime
)@svgr/core
, @svgr/plugin-jsx
, @tanstack/react-query
, @testing-library/dom
, @testing-library/jest-dom
, @testing-library/react
, @types/jest
, @types/node
, immer
, luxon
, ts-luxon
)ui/cluster-admin/docker-compose.yaml
ui/plugin-admin/docker-compose.yaml
ui/secret-admin/docker-compose.yaml
ui/team-admin/docker-compose.yaml
Dockerfile
golang 1.22
Dockerfile.dev-env
golang 1.22
alpine 3.20.1
Dockerfile.headscalectl
golang 1.22
Dockerfile.tailscale
golang 1.22
ghcr.io/tailscale/tailscale v1.68.1
Dockerfile.tcp-proxy
golang 1.22
.github/workflows/build-greenhousectl.yaml
actions/checkout v4
actions/setup-go v5
goreleaser/goreleaser-action v6
.github/workflows/ci-npm-packages.yaml
.github/workflows/codeql.yaml
actions/checkout v4
actions/setup-go v5
github/codeql-action v3
github/codeql-action v3
github/codeql-action v3
.github/workflows/docker-build.yaml
actions/checkout v4
sigstore/cosign-installer v3.5.0
docker/setup-qemu-action v3
docker/setup-buildx-action v3
docker/login-action v3
docker/metadata-action v5
docker/build-push-action v6
github/codeql-action v3
.github/workflows/helm-lint.yaml
actions/checkout v4
azure/setup-helm v4.2.0
actions/setup-python v5
helm/chart-testing-action v2.6.1
actions/github-script v7
.github/workflows/helm-push.yaml
actions/checkout v4
azure/setup-helm v4.2.0
actions/setup-python v5
docker/login-action v3
tj-actions/changed-files v44
.github/workflows/hugo.yaml
actions/checkout v4
actions/checkout v4
actions/configure-pages v5
actions/upload-pages-artifact v3
actions/deploy-pages v4
.github/workflows/kustomize-lint.yaml
actions/checkout v4
actions/setup-go v5
.github/workflows/label.yml
actions/labeler v5
.github/workflows/license.yaml
actions/checkout v4
apache/skywalking-eyes v0.6.0
EndBug/add-and-commit v9
.github/workflows/stale.yaml
actions/stale v9
.github/workflows/sync-issues-to-jira.yaml
actions/checkout v4
.github/workflows/ui-test.yml
actions/checkout v4
actions/setup-node v4
.github/workflows/unit-tests.yml
actions/checkout v4
actions/setup-go v5
go.mod
go 1.22
github.com/dexidp/dex/api/v2 v2.1.1-0.20240409110506-3705207f0190@3705207f0190
k8s.io/api v0.29.5
k8s.io/apiextensions-apiserver v0.29.5
k8s.io/apimachinery v0.29.5
k8s.io/cli-runtime v0.29.5
k8s.io/client-go v0.29.5
k8s.io/component-base v0.29.5
k8s.io/kubectl v0.29.5
sigs.k8s.io/controller-runtime v0.17.5
github.com/ghodss/yaml v1.0.0
github.com/jeremywohl/flatten/v2 v2.0.0-20211013061545-07e4a09fb8e4@07e4a09fb8e4
github.com/juanfont/headscale v0.22.3
github.com/oklog/run v1.1.1-0.20240127200640-eee6e044b77c@eee6e044b77c
github.com/onsi/ginkgo/v2 v2.19.0
github.com/onsi/gomega v1.33.1
github.com/pkg/errors v0.9.1
github.com/prometheus/client_golang v1.19.1
github.com/sirupsen/logrus v1.9.3
github.com/spf13/cobra v1.8.0
github.com/spf13/pflag v1.0.5
github.com/wI2L/jsondiff v0.5.2
go.uber.org/zap v1.27.0
golang.org/x/text v0.15.0
gopkg.in/yaml.v3 v3.0.1
gotest.tools/v3 v3.5.1
helm.sh/helm/v3 v3.14.4
k8s.io/api v0.29.5
k8s.io/apiextensions-apiserver v0.29.5
k8s.io/apimachinery v0.29.5
k8s.io/cli-runtime v0.29.5
k8s.io/client-go v0.29.5
k8s.io/kubectl v0.29.5
k8s.io/utils v0.0.0-20240502163921-fe8a2dddb1d0@fe8a2dddb1d0
sigs.k8s.io/controller-runtime v0.15.3
sigs.k8s.io/yaml v1.4.0
github.com/go-logr/logr v1.4.2
github.com/google/uuid v1.6.0
github.com/otiai10/copy v1.14.0
github.com/prometheus/common v0.53.0
golang.org/x/time v0.5.0
google.golang.org/grpc v1.64.0
google.golang.org/protobuf v1.34.1
k8s.io/klog/v2 v2.120.1
website/go.mod
go 1.20
charts/cors-proxy/values.yaml
charts/headscale/values.yaml
ghcr.io/gurucomputing/headscale-ui 2023.01.30-beta-1
postgres 16.3
charts/idproxy/values.yaml
charts/manager/values.yaml
registry.k8s.io/ingress-nginx/kube-webhook-certgen v20221220-controller-v1.5.1-58-g787ea74b6
charts/tailscale-proxy/values.yaml
charts/team-membership/values.yaml
charts/ui/values.yaml
nginx 1.26.0-alpine
charts/website/values.yaml
charts/greenhouse/Chart.yaml
ui/cluster-admin/package.json
@types/jest ^27.5.2
@types/node ^16.18.58
@types/react ^18.2.27
@types/react-dom ^18.2.12
interweave ^13.1.0
postcss-url ^10.1.3
ts-luxon ^4.4.0
typescript ^5.2.2
@babel/core ^7.20.2
@babel/preset-env ^7.20.2
@babel/preset-react ^7.18.6
@babel/preset-typescript ^7.23.2
@svgr/core ^7.0.0
@svgr/plugin-jsx ^7.0.0
@tanstack/react-query 4.28.0
@testing-library/dom ^8.19.0
@testing-library/jest-dom ^5.16.5
@testing-library/react ^13.4.0
@testing-library/user-event ^14.4.3
assert ^2.0.0
autoprefixer ^10.4.2
babel-jest ^29.3.1
babel-plugin-transform-import-meta ^2.2.0
esbuild ^0.17.19
eslint-plugin-react-hooks ^4.6.0
jest ^29.7.0
jest-environment-jsdom ^29.3.1
postcss ^8.4.21
postcss-url ^10.1.3
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
react-test-renderer 18.2.0
sapcc-k8sclient ^1.0.2
sass ^1.77.5
shadow-dom-testing-library ^1.7.1
tailwindcss ^3.3.1
util ^0.12.4
zustand ^4.1.1
@tanstack/react-query ^4.28.0
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
zustand ^4.1.1
ui/dashboard/package.json
@babel/core ^7.20.2
@babel/preset-env ^7.20.2
@babel/preset-react ^7.18.6
@svgr/core ^7.0.0
@svgr/plugin-jsx ^7.0.0
@tailwindui/react ^0.1.1
@testing-library/dom ^8.19.0
@testing-library/jest-dom ^5.16.5
@testing-library/react 13.4.0
@testing-library/user-event ^14.4.3
assert ^2.0.0
autoprefixer ^10.4.2
babel-jest ^29.3.1
babel-plugin-transform-import-meta ^2.2.0
esbuild ^0.20.2
immer ^9.0.21
jest ^29.3.1
jest-environment-jsdom ^29.3.1
postcss ^8.4.21
postcss-url ^10.1.3
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
react-test-renderer 18.2.0
sapcc-k8sclient ^1.0.2
sass ^1.77.5
shadow-dom-testing-library ^1.7.1
tailwindcss ^3.3.1
util ^0.12.4
zustand 4.5.2
prop-types ^15.8.1
react 18.2.0
react-dom ^18.2.0
zustand 4.5.2
ui/org-admin/package.json
@babel/core ^7.20.2
@babel/preset-env ^7.20.2
@babel/preset-react ^7.18.6
@svgr/core ^7.0.0
@svgr/plugin-jsx ^7.0.0
@tanstack/react-query 4.28.0
@testing-library/dom ^8.19.0
@testing-library/jest-dom ^5.16.5
@testing-library/react ^13.4.0
@testing-library/user-event ^14.4.3
assert ^2.0.0
autoprefixer ^10.4.2
babel-jest ^29.3.1
babel-plugin-transform-import-meta ^2.2.0
jest ^29.3.1
jest-environment-jsdom ^29.3.1
luxon ^2.3.0
postcss ^8.4.21
postcss-url ^10.1.3
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
react-test-renderer 18.2.0
sapcc-k8sclient ^1.0.2
sass ^1.77.5
shadow-dom-testing-library ^1.7.1
tailwindcss ^3.3.1
util ^0.12.4
zustand 4.5.2
esbuild ^0.19.5
@tanstack/react-query 4.28.0
luxon ^2.3.0
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
zustand 4.5.2
ui/plugin-admin/package.json
github-markdown-css ^5.5.1
react-markdown ^9.0.1
rehype-raw ^7.0.0
remark-gfm ^4.0.0
@babel/core ^7.20.2
@babel/preset-env ^7.20.2
@babel/preset-react ^7.18.6
@babel/preset-typescript ^7.24.1
@svgr/core ^7.0.0
@svgr/plugin-jsx ^7.0.0
@tanstack/react-query 4.28.0
@testing-library/dom ^8.19.0
@testing-library/jest-dom ^5.16.5
@testing-library/react ^13.4.0
@testing-library/user-event ^14.4.3
assert ^2.0.0
autoprefixer ^10.4.2
babel-jest ^29.3.1
babel-plugin-transform-import-meta ^2.2.0
esbuild ^0.19.5
jest ^29.3.1
jest-environment-jsdom ^29.3.1
luxon ^2.3.0
postcss ^8.4.21
postcss-url ^10.1.3
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
react-test-renderer 18.2.0
sapcc-k8sclient ^1.0.2
sass ^1.77.5
shadow-dom-testing-library ^1.7.1
tailwindcss ^3.3.1
util ^0.12.4
zustand 4.3.7
luxon ^2.3.0
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
zustand 4.3.7
ui/secret-admin/package.json
github-markdown-css ^5.5.1
kubernetes-types ^1.30.0
react-markdown ^9.0.1
rehype-raw ^7.0.0
remark-gfm ^4.0.0
@babel/core ^7.20.2
@babel/preset-env ^7.20.2
@babel/preset-react ^7.18.6
@babel/preset-typescript ^7.24.1
@svgr/core ^7.0.0
@svgr/plugin-jsx ^7.0.0
@tanstack/react-query 4.28.0
@testing-library/dom ^8.19.0
@testing-library/jest-dom ^5.16.5
@testing-library/react ^13.4.0
@testing-library/user-event ^14.4.3
assert ^2.0.0
autoprefixer ^10.4.2
babel-jest ^29.3.1
babel-plugin-transform-import-meta ^2.2.0
esbuild ^0.19.12
jest ^29.3.1
jest-environment-jsdom ^29.3.1
luxon ^2.3.0
postcss ^8.4.21
postcss-url ^10.1.3
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
react-test-renderer 18.2.0
sapcc-k8sclient ^1.0.2
sass ^1.77.5
shadow-dom-testing-library ^1.7.1
tailwindcss ^3.3.1
util ^0.12.4
zustand 4.5.2
luxon ^2.3.0
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
zustand 4.5.2
ui/team-admin/package.json
lodash ^4.17.21
@babel/core ^7.20.2
@babel/preset-env ^7.20.2
@babel/preset-react ^7.18.6
@svgr/core ^7.0.0
@svgr/plugin-jsx ^7.0.0
@testing-library/dom ^8.19.0
@testing-library/jest-dom ^5.16.5
@testing-library/react ^13.4.0
@testing-library/user-event ^14.4.3
assert ^2.0.0
autoprefixer ^10.4.2
babel-jest ^29.3.1
babel-plugin-transform-import-meta ^2.2.0
esbuild ^0.17.19
jest ^29.3.1
jest-environment-jsdom ^29.3.1
luxon ^2.3.0
postcss ^8.4.21
postcss-url ^10.1.3
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
react-test-renderer 18.2.0
sapcc-k8sclient ^1.0.2
sass ^1.77.5
shadow-dom-testing-library ^1.7.1
tailwindcss ^3.3.1
zustand 4.5.2
luxon ^2.3.0
prop-types ^15.8.1
react 18.2.0
react-dom 18.2.0
zustand 4.5.2
ui/types/package.json
kubernetes-types ^1.30.0
ui/utils/package.json
ts-luxon ^4.5.2
The open-source contributions within the ORA context should be presented to the top conferences to raise awareness and engage with the community.
Key topics are kubernetes, cloud-native, operations, devops, observability, security, compliance, ui, open-source, etc.
This issue tracks upcoming conferences we should consider showcasing Greenhouse:
Develop a distribution and installer for greenhouse artifacts on a Kubernetes platform.
Tasks:
(Medium) I'm annoyed but I'll live
In the organization tab all administrators and members can see a list of available PluginDefinitions. See the PluginDefinition CRD.
MVP:
Vision:
No response
(Medium) I'm annoyed but I'll live
Github Actions add the licences headers to every file. Also the generated CRDs.
When generating the CRDs locally these headers get removed. It would be nice if we can run the license header injector locally after the generating manifests etc.
1. `make generate-manifests`
No response
No response
alphav1
and documentation is in-progress to Project readme(Medium) I'm annoyed but I'll live
Currently the additional greenhouse values are added in the scope of the parent helm-chart of a plugin.
In order to use these values across parent helm-chart and all sub-charts of a plugin these values must be moved into the global values scope.
Helm Doc Reference
Acceptance Criteria:
.global
scope, No response
(Medium)
As user of Greenhouse I would like to see the current status of a Plugin in the Dashboard , so that I know if the resources on the remote cluster are up and running.
Currently there is no visibility into the runtime status of a Plugin's status. If a Plugin's HelmChart is deployed there is no indication if the workload resources actually are up and running.
Workload resources need to be checked if they either completed successfully, the desired replicas are ready, they are on the latest revision or readiness/liveness probes are failing.
Acceptance Criteria:
Pod
, Deployment
, ReplicaSet
, StatefulSet
, DaemonSet
, and ReplicationController
contained in the Plugins release are checked regularlyNo response
(Medium) I'm annoyed but I'll live
As a _ClusterAdmin_, I would like to maintain a Plugin preset for a type of Cluster, so that I do not have to configure every Plugin manually for every Cluster that is on-boarded
An Organization can have multiple Kubernetes Clusters that should be set-up in a unified way. To reduce the toil of doing the Plugin configuration manually, it would be great if the ClusterAdmin could configure a bundle/preset.
This bundle/preset should contain a list of Plugins, default configuration etc. .
It should be possible to override/ complement these values with values specific to the cluster.
Acceptance criteria:
No response
(Low) Something is a little off
Add Greenhouse StatusConditions to the TeamRoleBinding and populate them in the controller.
#238 introduces StatusConditions for TeamRoleBindings
(Medium) I'm annoyed but I'll live
Greenhouse creates a namespace in the managed cluster. This namespace contains by default the helm releases for all plugins installed to the cluster, as well as Greenhouse CR that are being propagated.
Currently this namespace is called as the Organization, where the cluster was on-boarded to. This is to change this behaviour to create a namespace called greenhouse
instead.
Acceptance criteria:
No response
Greenhouse Alertmanager Config should provide a basic framework to set up a list of different receivers like Slack channels or webhooks including authentication.
(Medium) I'm annoyed but I'll live
this is the first failing run:
https://github.com/cloudoperators/greenhouse/actions/runs/8601060342
which points to this commit:
a43ac46
We need to investigate what makes the docker buildx
fail for the Dockerfile.dev-env
as the commit does not include changes to either of:
./Dockerfile.dev-env
./cmd/dev-env
1. Go to https://github.com/cloudoperators/greenhouse/actions/runs/8601060342
2. Check logs for `Build and push Docker Image` step of https://github.com/cloudoperators/greenhouse/actions/runs/8601060342/job/23567388327
No response
No response
(Low) Something is a little off
Currently makefile defaults to amd64, ensure that the architecture of local machine is using.
No response
Umbrella issue for tracking K8S Access management.
Granular sub-issues can be found via label WP2.3.4.2 Kubernetes access management
.
Manage permissions in Kubernetes clusters based on greenhouse teams.
Acceptance criteria:
High
Greenhouse controllers emit the common set of metrics exposed with controller-runtime
. Additional instrumentation should give more insights into specific error conditions of a controller's reconciliation.
Furthermore, there are more components of Greenhouse which need to be actively monitoring such as cors-proxy, id-proxy, and service-proxy.
Metrics should be visualised with Plutono Dashboards so that the overall platform, as well individual components health, is easily consumable.
Metrics should be used to define PrometheusAlertRules so that failure conditions can be identified and proactively resolved.
Acceptance criteria:
No response
None
After renaming the Plugin Kind to PluginConfig the greenhouse.sap/plugin
must be migrated as well. https://github.com/cloudoperators/greenhouse/blob/main/pkg/apis/well_known.go#L34-L35
Acceptance Criteria:
No response
(Medium) I'm annoyed but I'll live
Organization administrators can deploy a Plutono Plugin into their namespace on the Greenhouse central cluster.
Plutono comes with a set of pre-installed kube-monitoring dashboards and has the capability to load custom dashboards from a git repo.
Acceptance criteria:
Plugin contains
Ingress configured per convention
1. plutono.<org_name>.greenhouse.<TLD> (with OIDC)
2. plutono-internal.<org_name>.greenhouse.<TLD> (w/o OIDC)
No response
(Low) Something is a little off
The ServiceProxyReconciler
automatically deploys a service-proxy
Plugin for each organization. The chart defines defaults for the image repository and tag.
Currently the reconciler overwrites the tag with the git version of the current deployed version of Greenhouse and it is not possible to configure the registry.
greenhouse/pkg/controllers/organization/service_proxy_controller.go
Lines 89 to 92 in 381ec74
It should be possible to configure these values in the greenhouse manager deployment, to enable using alternative registries to pull the container image from.
1. Deploy a new version of Greenhouse
2. ServiceProxyReconciler updates the Plugins with the lastest git version
3. service-proxy pods cannot pull the image
No response
No response
(Low) Something is a little off
Managing authentication for a fleet of Kubernetes clusters and a broad user base can be quite challenging.
Greenhouse can support as it has a holistic view on all clusters and their configuration (kubeconfigs) within an organization and should be used to generate kubeconfigs for users as shown below.
The task is to provide unified authentication as a core feature/admin plugin by implement a
cloudctl
)Example generated kubeconfig.yaml
:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: <CA>
server: <K8S API server>
name: <cluster name>
contexts:
- context:
cluster: <cluster name>
user: oidc@<cluster name>
name: <cluster name>
current-context: <cluster name>
kind: Config
preferences: {}
users:
- name: oidc@<cluster name>
user:
auth-provider:
config:
client-id: <client id>
client-secret: <client secret>
idp-issuer-url: <idp issuer url>
name: oidc
The OIDC settings can be consumed from the organization CRD (default).
Optionally, an org-wide alternative clientID, clientSecret should be configurable in case of different IDS applications.
No response
A violation against the OSS Rules of Play has been detected.
Rule ID: rl-reuse_tool-4
Explanation: Is it compliant with REUSE rules? No
Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html
This issue servers as a collection of e2e test scenarios:
(Medium) I'm annoyed but I'll live
As a Plugin Developer, I want to ensure that some defaults are not overwritten, to ensure the Plugin behaves as intended
Some PluginOptions
should be read-only to ensure that the Plugin behaves as the PluginDeveloper has intended. This could be security relevant defaults or simply making sure that any incompatible or problematic setting cannot be overwritten by a Plugin. E.g. enabling or disabled sub-charts etc.
Proposal: PluginOptions are extended with a readOnly
attribute. If this is set to true the ValidatingWebhooks for a Plugin ensure that any PluginOptionValue trying to overwrite the default is ignored. The AdmissionWebhook should either:
The build-in merge functions in helm.go must ensure that these defaults are not overwritten.
Open Question: Should it be possible to turn a Option into a read-only one later on? This would require some additional effort to ensure that this does not break existing PluginConfigs. Another option would be to ignore any overwrites by a Plugin or possibly bring up a warning.
Acceptance Criteria:
No response
Umbrella issue for tracking efforts on Kubernetes monitoring plugins. Granular subtopics can be found via the label WP2.3.4.3 Kubernetes Monitoring
.
The Greenhouse catalog offers plugins that install a collection of Kubernetes manifests, Plutono dashboards and Prometheus rules. They are combined with documentation and scripts to provide easy-to-use end-to-end Kubernetes cluster monitoring with Prometheus using the Prometheus Operator.
By architectural decision, the Alertmanager and Plutono are accepted as components in the central Greenhouse cluster. Other components run in remote Kubernetes clusters. Plugins are expected to be highly integrated so that certain configuration options work out of the box.
(Medium) I'm annoyed but I'll live
PluginDefinitions can specify defaults for their PluginOptions. The current implementation overrides these defaults if a Plugin supplies a corresponding PluginOptionValue.
In some cases this behavior is not ideal. For example a PluginDefinition specifies an PluginOption for ingress annotations with a default map
of annotations. In the case that PluginAdmin wants to add an additional annotations to the list, they must copy the defaults and supply them in the Plugin
together with the additional value.
For such cases it would be a convenience feature if the provided defaults for a map
or list
are merged with the values provided in a Plugin
Proposal: PluginOptions with list
and map
should be merged by default. Unwanted default keys should be removed by setting them to null
as it is the known behaviour of Helm: deleting a default key
Acceptance Criteria
PluginOptionValues
are merged with the defaults of PluginOptions for the types list
and map
No response
(Medium) I'm annoyed but I'll live
There are a limited amount of PluginDefinitions that an Organization may deploy to their namespace in the Greenhouse Central cluster. (currently restricted in code: #41)
These PluginDefinitions should only be configurable for an Organization Admin and may only be installed once in certain cases such as Teams2Slack, Alerts etc...
Acceptance Criteria:
No response
(Medium) I'm annoyed but I'll live
Currently the ui
container provided for greenhouse deployed with the helm charts serves an index.html
file with a script tag importing the core greenhouse-ui
javascript bundle from an external source.
We aim to provide a container that serves all bundles for the microfrontends the greenhouse core ui consists of from localhost
and therefore has no external dependencies.
Necessary steps:
greenhouse
and the greenhouse-management
app from https://github.com/sapcc/juno/tree/main to this repoNo response
(Low) Something is a little off
There are currently direct imports and uses of the following logging libraries within Greenhouse.
log
go.uber.org/zap
github.com/sirupsen/logrus
github.com/go-logr/logr
k8s.io/klog/v2
sigs.k8s.io/controller-runtime/pkg/log
Where possible we should aim to unify this list. As part of this refactoring the logging should also been made contextual, where this is possible and it adds additional value.
Context:
K8S SIG Instrumentation Logging Guidelines
K8S Structured Logging Guidline
No response
(Medium) I'm annoyed but I'll live
Acceptance Criteria:
No response
None
Currently the HelmController only checks if a Plugin's Release could be installed/upgraded successfully. However, it there are no additional checks to verify that the Helm Release is working as expected.
With Chart Tests it is possible to run a set of tests after a Helm action has been performed to validate that the deployed components work as intended.
Example tests:
Validate that your configuration from the values.yaml file was properly injected.
Make sure your username and password work correctly
Make sure an incorrect username and password does not work
Assert that your services are up and correctly load balancing
etc.
Acceptance Criteria
No response
Actively work on the open-sourcing Greenhouse considering codebase dependencies, documentation, removal of all internal references, etc. and migrate to this repository.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.