prometheus-community / helm-charts Goto Github PK
View Code? Open in Web Editor NEWPrometheus community Helm charts
License: Apache License 2.0
Prometheus community Helm charts
License: Apache License 2.0
Quick how-to, to increase the bus factor:
Bring down the stable
charts code
git clone [email protected]:helm/charts.git prometheus-helm-charts/
cd prometheus-helm-charts/
Filter only prometheus charts and rename stable
dir to charts
while retaining direct commit history all in one go, with git-filter-repo
brew install git-filter-repo
git filter-repo --path-glob 'stable/prometheus*' --path-rename stable/:charts/
If you want to adopt main
instead of master
branch naming, do it now. See #6
git checkout -b main
git branch -D master
Set the remote and push. See #11 for context
git remote add origin [email protected]:scottrigby/prometheus-helm-charts.git
git push -u origin main
There are still references to https://github.com/scottrigby/prometheus-helm-charts
in the gh-pages helm repo index.yaml file. These should now be changed to https://prometheus-community.github.io/helm-charts
.
This is not a functional change, since [GitHub forwards transferred repo URLs](All links to the previous repository location are automatically redirected to the new location):
All links to the previous repository location are automatically redirected to the new location
But it will look nicer 😄
Note we're already holding PRs in stable (#13)
Issue options:
helm/charts
to helm/prometheus-helm-charts
helm/prometheus-helm-charts
to prometheus-community/helm-charts
Since the repo has already been transferred we can only do option 1 above.
PR options:
AFAIK there's no nice way for us to automate transferring open PRs from one repo to another and still allow the original PR author to own the PR. So I think our best option is to close open PRs in helm/charts
with a friendly note on how they can do re-open the PR themselves (1. add new remote locally, 2. open PR from the same branch the initially did).
It might be nice to bundle alertmanager with kube-prometheus-stack so that it matches what prometheus-operator provided out of the box.
Describe the bug
When running helm lint
for the prometheus-blackbox-exporter
chart 4.3.1
it fails with the following errors:
==> Linting /tmp/750049035/monitoring/prometheus-blackbox-exporter/helm-charts-stable/prometheus-blackbox-exporter/4.3.0/prometheus-blackbox-exporter
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/role.yaml: the kind "rbac.authorization.k8s.io/v1beta1 Role" is deprecated in favor of "rbac.authorization.k8s.io/v1 Role"
[ERROR] templates/rolebinding.yaml: the kind "rbac.authorization.k8s.io/v1beta1 RoleBinding" is deprecated in favor of "rbac.authorization.k8s.io/v1 RoleBinding"
Error: 1 chart(s) linted, 1 chart(s) failed
Version of Helm and Kubernetes:
Helm v3.3.1
Kubernetes v1.19.0
Which chart:
prometheus-blackbox-exporter
What happened:
Fails linting due to a deprecated api version in role.yaml
and rolebinding.yaml
What you expected to happen:
Linting to succeed
How to reproduce it (as minimally and precisely as possible):
charts/prometheus-blackbox-exporter
helm lint
Anything else we need to know:
Nope
Note these PRs must be done properly, per https://github.com/helm/charts/blob/master/PROCESSES.md#deprecating-a-chart
(Repost of helm/charts#23535)
Describe the bug
Wrong configuration default for config.modules.http_2xx.http.valid_http_versions.
Version of Helm and Kubernetes:
version.BuildInfo{Version:"v3.2", GitCommit:"", GitTreeState:"", GoVersion:"go1.14.3"}
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.6", GitCommit:"dff82dc0de47299ab66c83c626e08b245ab19037", GitTreeState:"archive", BuildDate:"2020-07-20T23:19:14Z", GoVersion:"go1.14.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.8-eks-e16311", GitCommit:"e163110a04dcb2f39c3325af96d019b4925419eb", GitTreeState:"clean", BuildDate:"2020-03-27T22:37:12Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
stable/prometheus-blackbox-exporter
What happened:
Probing HTTP/2.0 sites results in failures.
What you expected to happen:
Probing HTTP/2.0 sites should work.
How to reproduce it (as minimally and precisely as possible):
Run the default setup against any HTTP/2.0 site.
Anything else we need to know:
This can be fixed by replacing valid_http_versions: ["HTTP/1.1", "HTTP/2"]
with valid_http_versions: ["HTTP/1.1", "HTTP/2.0"]
.
See prometheus/blackbox_exporter#658
As a follow-up of our discussion (me and @scottrigby) - it should be beneficial to add a GitHub Action that does Mark Down linting.
Describe the bug
The linked-to yml for etcd's prometheus rules/alerts does not exist anymore.
I'm using a managed cluster so I can't access etcd metrics anyway, but I noticed this while running the hack scripts.
Describe the bug
The helm lint (for Helm 3.3) fails for the prometheus-adapter
Helm chart because of the invalid resource name that is not compliant with Kubernetes name requirements. The error is the following:
templates/custom-metrics-apiserver-auth-delegator-cluster-role-binding.yaml: object name does not conform to Kubernetes naming requirements: "prometheus-adapter:system:auth-delegator"
Particularly, it does not like the colons in the resource name.
Helm uses the following regular expression to check the validity of a resource name:
^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
I believe the name should become: prometheus-adapter-system-auth-delegator
Version of Helm and Kubernetes:
Helm: 3.3.0
Kubernetes: 1.18.7
Which chart:
What happened:
helm lint
command fails
What you expected to happen:
helm lint
command passes
How to reproduce it (as minimally and precisely as possible):
Using Helm 3.3 run the following commands:
helm repo add stable https://kubernetes-charts.storage.googleapis.com
helm pull stable/prometheus-adapter --untar
helm lint stable/prometheus-adapter
The output is:
==> Linting stable/prometheus-adapter
[INFO] Chart.yaml: icon is recommended
[ERROR] templates/custom-metrics-apiserver-auth-delegator-cluster-role-binding.yaml: object name does not conform to Kubernetes naming requirements: "prometheus-adapter:system:auth-delegator"
Error: 1 chart(s) linted, 1 chart(s) failed
scottrigby/prometheus-helm-charts
prometheus-community
(#11)A simple approach is to install https://github.com/apps/dco
Hi team,
I wasn't able to find how to add all metrics from different namespaces to monitoring. It looks like only metrics in deployment
namespace with kube-system and default were added
All services in custom namespaces were added successfully with additionalServiceMonitors section, but how may i add non services metrics - volumes, ingress etc. I tried this part in values.yaml ## Namespaces to scope the interaction of the Prometheus Operator and the apiserver (allow list) but without success.
I found only this workaround https://github.com/prometheus-operator/kube-prometheus#adding-additional-namespaces-to-monitor and found this solution prometheus-operator/prometheus-operator#2890 (comment)
but it doesn't help. Should i create role and rolebinding in every necessary namespace or something else?
eks 1.17
prometheus-operator-9.3.0
app version 0.38.1
Thank you in advance.
Ideally this should happen before indexing/releasing first version of each chart, otherwise when aggregated in the hubs the README will refer stable
instead of the new prometheus-community
repo.
helm/charts#23542 recreated here
Describe the bug
prometheus-node-exporter ignores taints
Version of Helm and Kubernetes:
helm 3, k8s 1.16.3
Which chart:
kube-prometheus-stack
What happened:
Taints: node.kubernetes.io/os=windows:NoSchedule
Taints: search=true:NoSchedule
the above taints are being ignored and the node-exporter is scheduled regardless on nodes, get stuck at container creating for windows nodes
monitoring kube-prometheus-stack-prometheus-node-exporter-2l5wz 1/1 Running 0 5m28s
monitoring kube-prometheus-stack-prometheus-node-exporter-4vmt4 1/1 Running 0 5m28s
monitoring kube-prometheus-stack-prometheus-node-exporter-5lkwh 0/1 ContainerCreating 0 5m28s
monitoring kube-prometheus-stack-prometheus-node-exporter-6l7bc 1/1 Running 0 5m28s
monitoring kube-prometheus-stack-prometheus-node-exporter-89926 1/1 Running 0 5m28s
monitoring kube-prometheus-stack-prometheus-node-exporter-bbpcg 0/1 ContainerCreating 0 5m28s
monitoring kube-prometheus-stack-prometheus-node-exporter-l9p4r 1/1 Running 0 5m27s
What you expected to happen:
node-exporter should not be scheduled on windows nodes
How to reproduce it (as minimally and precisely as possible):
setup a cluster with taints
helm install [RELEASE_NAME] prometheus-community/kube-prometheus-stack
workaround:
--set prometheus-node-exporter.nodeSelector."beta\.kubernetes\.io/os"=linux
Hi,
First of all thanks to the team for making such a wonderful helm charts for prometheus.
This issue occurs when I try to do PVC for my existing PV.
Though I see the PV is getting Bound to the Pod but my Pod throws error "ContainerCreating" and I see the below error.
Unable to attach or mount volumes: unmounted volumes=[storage-volume], unattached volumes=[storage-volume prometheus-alertmanager-token-ht648 config-volume]: failed to get Plugin from volumeSpec for volume "storek8s" err=no volume plugin matched
I see lot of online suggestions for adding FlexVolume or plugin but not sure how we can implement that in the existing helm charts values.yml
Please help me with the same.
Below is the part of the PersistentVolume for alertmanager in values.yml
persistentVolume:
## If true, alertmanager will create/use a Persistent Volume Claim
## If false, use emptyDir
##
enabled: true
## alertmanager data Persistent Volume access modes
## Must match those of existing PV or dynamic provisioner
## Ref: http://kubernetes.io/docs/user-guide/persistent-volumes/
##
accessModes:
- ReadWriteMany
## alertmanager data Persistent Volume Claim annotations
##
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"storek8s","namespace":"default"},"spec":{"accessModes":["ReadWriteMany"],"resources":{"requests":{"storage":"2Gi"}}}}
## alertmanager data Persistent Volume existing claim name
## Requires alertmanager.persistentVolume.enabled: true
## If defined, PVC must be created manually before volume will be bound
existingClaim: ""
## alertmanager data Persistent Volume mount root path
##
mountPath: /data
volumes:
- flexVolume:
driver: fstab/cifs
fsType: cifs
options:
mountOptions: dir_mode=0755,file_mode=0644,noperm
networkPath: //store/ThinkBigLogs/k8s
secretRef:
name: cifs-secret-test
name: storek8s2
## alertmanager data Persistent Volume size
##
size: 2Gi
## alertmanager data Persistent Volume Storage Class
## If defined, storageClassName: <storageClass>
## If set to "-", storageClassName: "", which disables dynamic provisioning
## If undefined (the default) or set to null, no storageClassName spec is
## set, choosing the default provisioner. (gp2 on AWS, standard on
## GKE, AWS & OpenStack)
##
storageClassName: ""
## alertmanager data Persistent Volume Binding Mode
## If defined, volumeBindingMode: <volumeBindingMode>
## If undefined (the default) or set to null, no volumeBindingMode spec is
## set, choosing the default mode.
##
volumeBindingMode: ""
Existing prometheus PRs in stable are on hold for now (see linked PRs on prometheus-community/community#28), but we don't have any automated way to hold new PRs that may open between now and when that issue is resolved (this new helm repo ready to be transferred to prometheus-community, stable prometheus charts deprecated, new helm repo with charts listed on the hubs).
Maintainers: Please help with this if you see new PRs for prometheus charts open in the meantime.
Let's keep this open to track the effort, until the above is complete.
I noticed that several people approved #51 but no one merged it. What should our process for this look like?
For option 3 we could look into https://github.com/pascalgn/automerge-action
Which option would you prefer?
stable
OWNERS
filesDo we want to keep this level of granularity, or would it be better to give all collaborators write access to all charts in this repo? Let's discuss in comments below…
I initially removed these from the READMEs where they existed, but am rethinking that now. I removed them because they were not consistent. But maybe it's better to make them consistent the other way, by adding them back, and then requiring that moving ahead. https://sembr.org/ makes a compelling case for this, and I'm inclined to agree.
This issue is only about whether maintainers also agree, and want this to be part of this repo style guide. Thoughts?
Also see this related issue about whether to enforce markdownlint in general: #19
For options, see:
This chart will be renamed, but first must be deprecated before the prometheus-community/helm-charts repo is indexed, so that it won't be listed in the hubs. See this prometheus-community issue for reasoning and next steps.
Is your feature request related to a problem? Please describe.
kube-prometheus
has a compatibility matrix at https://github.com/prometheus-operator/kube-prometheus#kubernetes-compatibility-matrix . Since this helm chart is based on kube-prometheus
, I was wondering if this chart would also have compatibility matrix.
Describe the solution you'd like
If the latest version of this chart is not compatible with all versions of k8s (1.10+ as mentioned in the docs), a compatibility chart would help a lot in figuring out which version of this chart should be used with a given k8s version.
Describe alternatives you've considered
This feature request assumes that like kube-prometheus
, this helm chart is not compatible with all major k8s versions. If this helm chart is compatible with all major k8s versions, please feel free to close it.
Additional context
None
Do after #9
Describe the bug
Prometheus server container continually restarts after receiving SIGTERM. Container will be up for a few minutes, receive SIGTERM, go down for a few minutes, restart, repeat.
Version of Helm and Kubernetes:
Helm:
helm version
version.BuildInfo{Version:"v3.3.0", GitCommit:"8a4aeec08d67a7b84472007529e8097ec3742105", GitTreeState:"dirty", GoVersion:"go1.14.6"}
Kubernetes:
kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.3", GitCommit:"2e7996e3e2712684bc73f0dec0200d64eec7fe40", GitTreeState:"clean", BuildDate:"2020-05-20T12:52:00Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"fdba62c353cc548995bbe730321f64176e4f6e4b", GitTreeState:"clean", BuildDate:"2020-04-08T18:15:19Z", GoVersion:"go1.13.8 BoringCrypto", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
stable/prometheus
What happened:
The prometheus-server container regularly restarts after receiving SIGTERM and prometheus is unavailable for several minutes at a time.
What you expected to happen:
Prometheus to continue running while my workflows are running.
How to reproduce it (as minimally and precisely as possible):
Happened after installing helm using homebrew (brew install helm
), then prometheus (helm install prometheus stable/prometheus
). Installation and initial setup works fine, but restarting problems occur several minutes after installation.
Anything else we need to know:
Moving original issue here as instructed.
I've tried other suggestions mentioned in other GitHub issues (increasing memory allocated to prometheus-server, increasing initial delay for liveness/readiness checks) and so far nothing has helped.
My apologies if this issue is with my own cluster configuration rather than the helm chart, but any suggestions would be greatly appreciated.
Thanks!
We would like to add our own dashboards, rules, and alerts, but they are private, and we do not want them pushed upstream. We also want to be able to modify those made by kube-prometheus via jsonnet. To do these things, we are vendoring these helm charts as-is, then generating the json for these things via jsonnet with kube-prometheus, then finally piping them into a modified version of the hack scripts to create the templates for the helm charts.
If some of the heavy lifting (particularly the loops) were pulled into their own functions, then it would be easier to write slightly modified versions of the hack script, and I won't need to merge with updates pulled from upstream as often (that hasn't really been an issue, but if all the main functionality is available in specific functions, then I have more confidence that it won't be). It would be nice to just copy these hack scripts into my own python module for me to use the functions provided. I assume there would still be some churning as there's no API guarantees in these hack scripts, but it seems more manageable at a function-level.
This is the "easy" feature request, though I guess this leads to what I'm ultimately trying to achieve: the ability to add rules, dashboards, and alerts (as well as modify the ones from kube-prometheus), then easily be able to deploy them as part of the helm charts (with all the helm templating, etc.) without having to first push these somewhere public.
Is your feature request related to a problem? Please describe.
Having a "static" set of dashboards, rules, and alerts won't work for us. We need to be able to modify things in the jsonnet as well as add our own stuff. However, using helm is still a huge benefit, in terms of switching them on/off with the values.yaml and using helm templating for variables not known until deployment time (i.e. not known when the charts are generated with these hack scripts).
Describe the solution you'd like
For the easy solution, I would just like any loops or non-trivial functionality to be pulled into functions, so the main
function is simplified and I don't need to worry about having to merge things when pulling upstream changes as often.
Ultimately, I'm picturing these hack scripts basically being a helm chart "generator" (since helm natively doesn't support jsonnet or workflows like this), and I'd like to use functions from these hack.py
scripts to help with that.
Describe alternatives you've considered
We've considered using just kube-prometheus without helm, but given that kubectl apply --prune
is still alpha, helm seems to be best for packaging things. Plus the helm templating is a huge plus as well.
HTH make a PR for this.
Subject is self-explanatory.
Hi, at
It would be good to use the newer container image from https://hub.docker.com/r/ghostunnel/ghostunnel/tags as this supports ARM64.
Note that this would require a version bump from v1.5.2
to v1.5.3
of this image. Happy to submit a PR, but just wanted to check first...
See:
We may as well do it for this repo, since helm/chart-testing, helm/chart-releaser, and the Helm GitHub Actions have been verified to work well with branch renaming.
Hi,
It appears as if the default values.yaml
installs the grafana chart with it's "test framework" enabled.
I think this should be disabled by default, for a standard production deployment. Is it worth updating this chart's values.yaml
to default that to off?
Details:
https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml#L64
Happy to add a PR if we agree.
Do after #12
Describe the bug
I don't manage to install prometheus-kube-stack , and I don't understand why.
I am on an AWS EC2 instance with Koops and Kubectl.
Version of Helm and Kubernetes:
version.BuildInfo{Version:"v3.3.1", GitCommit:"249e5215cde0c3fa72e27eb7a30e8d55c9696144", GitTreeState:"clean", GoVersion:"go1.14.7"}
Helm Version:
Which chart:
prometheus-kube-stack
Which version of the chart:
last version
What happened:
impossible to install prometheus-kube-stack
What you expected to happen:
to install smootly prometheus-kube-stack
How to reproduce it (as minimally and precisely as possible):
tape this:
helm install monitoring prometheus-community/kube-prometheus-stack
Describe the bug
Relative links in chart READMEs cannot be rendered by aggregator hubs like Artifact Hub. See 
To fix:
All chart READMEs Should replace relative links with full URL links.
Version of Helm and Kubernetes:
N/A
Which chart:
All
What happened:
What you expected to happen:
How to reproduce it:
Anything else we need to know:
I see that we are moving prometheus charts from stable to this repo. what about other charts that prometheus-operatror deploy like grafana, kube-state-metrics. ?
https://github.com/scottrigby/prometheus-helm-charts/blob/07435072d0eda4fd6c5fd5e30371286847f3813f/charts/prometheus/values.yaml#L1203-L1544 seems like it was originally based on https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml but has strayed, should we keep it in sync?
Hi, I've been looking everywhere but I can't find how to upgrade stable/prometheus-operator to the renamed chart. I looked in open issues but found nothing.
I've never upgraded a renamed chart, I tried to look it up with no luck. Can anyone point me to that if it's anywhere?
I guess it's worth mentioning it in https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/README.md ?
Per #20 we have CODEOWNERS
so people who maintain the 17 individual prometheus charts can still do so safely while sharing a common GitHub/helm repo with common CI/CD, related issues where appropriate, etc. This will allow the prometheus community charts to grow with new charts, and new maintainers as needed (existing maintainers of a chart can approve new maintainers, and repo admins can add them to the CODEOWNERS
file).
Now that the repo has transferred, we are moving users from collaborators to GitHub teams.
This is the team structure:
helm-charts
: top level team for all members (Read
access to this git repo)
helm-charts-admins
: nested team (Admin
access to this git repo)helm-charts-maintainers
nester team (Write
access to this git repo)Currently @brancz @SuperQ and I are in the helm-charts-admins
team. It wouldn't make sense for all chart maintainers to also do this (that would remove the CODEOWNERS
benefit mentioned above). I don't know if there is criteria within the prometheus-community org for who can administer the git repo – I have asked, and we'll update this issue with an answer on that.
In the meantime, and apart from that, would it make sense for chart maintainers to have perhaps 2 repo maintainers, and define the duties for that team (what they are expected to do and what they will not do, like merge PRs for other charts they don't maintain). As well as a process for that (perhaps starting with people who have helped with the repo side of things, and then some kind of rotation process)?
I don't need to continue as an admin on this repo now that it's set up, however I'd be ok with staying on that team if people would like me to continue to help as backup.
Let's discuss this here. This repo is co-owned by the charts maintainers and ultimately governed by the prometheus-community org. Just wanted to start the conversation, but I think it's up to all of you. We can only assign 10 people to an issue, so CCing you all below instead:
CC CODEOWNERS:
If desired, please incorporate https://github.com/naseemkullah/naseem-charts/tree/master/charts/alertmanager to the repo, we could swap it in the (vanilla) prometheus chart. cc @zanhsieh
Is your feature request related to a problem? Please describe.
We want to mount multiple configmaps as alerting rules via extraConfigmapMounts
, as described in this comment: helm/charts#9254 (comment)
However, one configmap prometheus-default-alerts
is available by default (managed by the team that sets up prometheus, and is deployed before the helm chart), but another one, prometheus-alerts
, should only be mounted if it is available (managed by another team).
Currently, when I deploy prometheus, it cannot start, since the second configmap is not available. (MountVolume.SetUp failed for volume "server-prometheus-alerts" : configmap "prometheus-alerts" not found
)
Since kubernetes seems to be able to mount configmaps only if they are available, at least stated in https://stackoverflow.com/a/48228418/2286108 , it would be nice if the helm chart would provide this functionality for mounts too.
Describe the solution you'd like
It would be great if there would be a flag like show in the code piece below, that would allow to mount configmaps only if they are available:
extraConfigmapMounts:
- name: prometheus-default-alerts
mountPath: /etc/config/alerts
configMap: prometheus-default-alerts
readOnly: true
- name: prometheus-alerts
mountPath: /etc/config/alerts
configMap: prometheus-alerts
readOnly: true
optional: true # <-- this one is new
If a similar functionality is already available, please let me know, but I didn't find a hint in values.yaml or in the documentation.
Additionally, this would or example also be a good idea for alertmanager.configFromSecret
and other places where configmaps/secrets are mounted.
If additional information is required (e.g. current values.yaml), please let me know!
Describe the bug
Running helm lint
fails with the following error:
$ helm lint
==> Linting .
[ERROR] templates/rbac/alertmanager-clusterrole.yaml: the kind "rbac.authorization.k8s.io/v1beta1 ClusterRole" is deprecated in favor of "rbac.authorization.k8s.io/v1 ClusterRole"
[ERROR] templates/rbac/alertmanager-clusterrolebinding.yaml: the kind "rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding" is deprecated in favor of "rbac.authorization.k8s.io/v1 ClusterRoleBinding"
[ERROR] templates/rbac/pushgateway-clusterrole.yaml: the kind "rbac.authorization.k8s.io/v1beta1 ClusterRole" is deprecated in favor of "rbac.authorization.k8s.io/v1 ClusterRole"
[ERROR] templates/rbac/pushgateway-clusterrolebinding.yaml: the kind "rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding" is deprecated in favor of "rbac.authorization.k8s.io/v1 ClusterRoleBinding"
[ERROR] templates/rbac/server-clusterrole.yaml: the kind "rbac.authorization.k8s.io/v1beta1 ClusterRole" is deprecated in favor of "rbac.authorization.k8s.io/v1 ClusterRole"
[ERROR] templates/rbac/server-clusterrolebinding.yaml: the kind "rbac.authorization.k8s.io/v1beta1 ClusterRoleBinding" is deprecated in favor of "rbac.authorization.k8s.io/v1 ClusterRoleBinding"
Error: 1 chart(s) linted, 1 chart(s) failed
Version of Helm and Kubernetes:
$ helm version
version.BuildInfo{Version:"v3.3.1", GitCommit:"249e5215cde0c3fa72e27eb7a30e8d55c9696144", GitTreeState:"dirty", GoVersion:"go1.15"}
Kubernetes Version:
$ kubectl version
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T21:54:15Z", GoVersion:"go1.15", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.6-1+64f53401f200a7", GitCommit:"64f53401f200a7a5977955a74ad3f997302774ca", GitTreeState:"clean", BuildDate:"2020-07-15T19:59:02Z", GoVersion:"go1.14.5", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
prometheus
Which version of the chart:
11.13.1
What happened:
Linting fails
What you expected to happen:
Linting to succeed
How to reproduce it (as minimally and precisely as possible):
helm lint
Anything else we need to know:
Nope
Fixes: prometheus-community/community#28 (comment)
prometheus-operator
to kube-prometheus
a blocker?" belowAre we good to transfer ownership now?
Note: Final decision is for @brancz, as he's sponsoring the repo transfer for the prometheus-community
.
This temporary repo location is working. You can test it now:
$ helm repo add temp-prometheus-community https://scottrigby.github.io/prometheus-helm-charts
"temp-prometheus-community" has been added to your repositories
$ helm repo update
$ helm search repo prometheus | grep temp
temp-prometheus-community/prometheus 11.12.1 2.20.1 Prometheus is a monitoring system and time seri...
temp-prometheus-community/prometheus-adapter 2.5.1 v0.7.0 A Helm chart for k8s prometheus adapter
temp-prometheus-community/prometheus-blackbox-e... 4.3.1 0.16.0 Prometheus Blackbox Exporter
temp-prometheus-community/prometheus-cloudwatch... 0.8.4 0.8.0 A Helm chart for prometheus cloudwatch-exporter
temp-prometheus-community/prometheus-consul-exp... 0.1.6 0.4.0 A Helm chart for the Prometheus Consul Exporter
temp-prometheus-community/prometheus-couchdb-ex... 0.1.2 1.0 A Helm chart to export the metrics from couchdb...
temp-prometheus-community/prometheus-mongodb-ex... 2.8.1 v0.10.0 A Prometheus exporter for MongoDB metrics
temp-prometheus-community/prometheus-mysql-expo... 0.7.1 v0.11.0 A Helm chart for prometheus mysql exporter with...
temp-prometheus-community/prometheus-nats-exporter 2.5.1 0.6.2 A Helm chart for prometheus-nats-exporter
temp-prometheus-community/prometheus-node-exporter 1.11.2 1.0.1 A Helm chart for prometheus node-exporter
temp-prometheus-community/prometheus-operator 9.3.2 0.38.1 DEPRECATED - This chart will be renamed. See ht...
temp-prometheus-community/prometheus-postgres-e... 1.3.1 0.8.0 A Helm chart for prometheus postgres-exporter
temp-prometheus-community/prometheus-pushgateway 1.4.2 1.2.0 A Helm chart for prometheus pushgateway
temp-prometheus-community/prometheus-rabbitmq-e... 0.5.6 v0.29.0 Rabbitmq metrics exporter for prometheus
temp-prometheus-community/prometheus-redis-expo... 3.5.1 1.3.4 Prometheus exporter for Redis metrics
temp-prometheus-community/prometheus-snmp-exporter 0.0.6 0.14.0 Prometheus SNMP Exporter
temp-prometheus-community/prometheus-to-sd 0.3.1 0.5.2 Scrape metrics stored in prometheus format and ...
After the transfer – as documented in this repo README and all the charts READMEs – you should be able to do the same with:
$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
prometheus-operator
to kube-prometheus
a blocker?@brancz see how the temp-prometheus-community/prometheus-operator
is marked DEPRECATED
in the output? Because it's also flagged in Chart.yaml
it will be hidden in the hubs like Helm Hub (and Artifact Hub, it's successor). I also made sure to VERY CLEARLY mark the chart README with a huge deprecation and warning sign (as well as CLI output if someone tries to install it after missing all that) so no one should mistake it as an active chart.
Regarding the order of this repo transfer and finishing fixing the renamed chart (ongoing in PR #1), I see two options:
stable
repo immediately, and allowing users to begin contributing directly to themstable/prometheus-operator
will have to wait until the newly named prometheus-community/kube-prometheus
chart is finished to use it. Then again, they will have to wait until it's ready either waystable/prometheus-operator
chart to prometheus-community/kube-prometheus
stable/prometheus-operator
chart it's difficult to predict a completion timeline. Also if we transferred first we could still announce the planned change (and link to the PR), which may encourage more participating in review/testing to get it done sooner than it would have otherwise?I'm clearly in favor of option 1. Does anyone disagree?
All identified issues so far in this gh project prepare repo for transfer to prometheus-community/helm-charts are complete. The other open issues (apart from #13, which I'm keeping open to remind us to continue holding PRs in stable
until this is done so we can close them) either must or can wait until after the transfer.
Not sure when this should happen, but once the chart is ready for this, we can move to quay.io/prometheus-operator/prometheus-operator.
Related: prometheus-operator/prometheus-operator#3416 (comment)
I am trying to add a new label called "teamname" to the metrics scraped on kube-state-metrics.So my objective is to add teamname as an additional label to the metrics scraped at kube-state-metrics so in the PrometheusRule we can set the specific team name on the label.
So tried with the below config.But I dont see this new label being added to the kube-state-metrics in Prometheus Service Discovery page.Please let me know whats the correct method to do this.
Objective: is to add new label named "teamname" so based upon the metrics,the team name can be set.
prometheus:
prometheusSpec:
additionalScrapeConfigs:
Prometheus Operator chart version: 9.3.1
Insert image tag or Git SHA here
quay.io/coreos/prometheus-operator:v0.38.1
Kubernetes version information:
kubectl version 1.15
Kubernetes cluster kind: EKS
Do after #8
Good summary from @torstenwalter #21 (comment):
When introducing CODEOWNERS we will have an issue with charts which only have one maintainers. If that maintainer make a change then he is not able to approve it. Repository admins would need to use their "superpower" to override the required review and can merge it. That might be ok for the start, but I would suggest that we try to add at least a second maintainer there.
Also from #21 (comment):
Would be great if we could find volunteers here or even better if the chart maintainers could try to motivate people who already contributed to the chart to become maintainer.
We have arrived at a process:
Additional maintainer processes should be discussed in a separate issue, and documented in the PROCESSES file
Affected charts since issue was opened:
📊 Maintainers poll
Could any of your charts use additional maintainers?Let's use this issue to discuss. If it gets unwieldy, after we move to the
prometheus-community
GH org, we could consider enabling team discussions (but let's cross that bridge when we get there).
In the GH Actions, we have the following in L30-L33. What is the purpose of adding those repo?
- name: Add dependency chart repos
run: |
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com/
After #11
Until #11 this repo is under my individual user account, therefore there is only one "collaborator" access level. But after this transfer, we will have options. One suggestion #12 (comment) was that all chart maintainers be given repo "Maintain" access level.
CODEOWNERS
? I don't have a current repo set up for testing thisA 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.