helm/charts 14059
Curated applications for Kubernetes
Manage & automate Grafana with easy wizzy
A webapp for working with Hashicorp's Vault https://github.com/hashicorp/vault
Utility to simplify running applications in docker containers
Convert docker-compose service files to Kubernetes objects.
Alpine based bind setup using dockerize
Terraform For Teams
AWS SDK for the Go programming language.
push eventsstarcher/helm-charts
commit sha ce43001c7752b9b3693704ed4519652cdd53743c
add chart for sstarcher/helm-exporter
push time in 14 days
created tagsstarcher/helm-exporter
Export helm stats into the Prometheus format
created time in 14 days
pull request commentsstarcher/helm-exporter
Add option to set the value to helm release's timestamp
Bah, we should have updated the README.md to add info about the new metric.
comment created time in 15 days
PR merged sstarcher/helm-exporter
The helm chart cannot be applied without this PR due to wrong indentation of labels in the ConfigMap template.
pr closed time in 15 days
push eventsstarcher/helm-exporter
commit sha 61daf2c6208f7adabe20bc0f82dc55a996464267
Fix the ConfigMap template's indentation
push time in 15 days
pull request commentsstarcher/helm-exporter
Add option to set the value to helm release's timestamp
Thanks for your contributions!
comment created time in 15 days
push eventsstarcher/helm-exporter
commit sha f63863ef32df40194fd5ead7f1ea08f98c885e3b
Add option to set the value to helm release's timestamp (#36) add option to set the value to helm release's timestamp
push time in 15 days
PR merged sstarcher/helm-exporter
Recent versions of Grafana (I am testing with v6.7.1) have a "Series value as timestamp" option which can be used with the timestamp option implemented in this PR, in order to use the helm_chart_info metric for Grafana annotations pulled from Prometheus.
https://grafana.com/docs/grafana/latest/reference/annotations/#querying-other-data-sources
pr closed time in 15 days
Pull request review commentsstarcher/helm-exporter
Add option to set the value to helm release's timestamp
func runStats(config config.Config) { releaseName := item.Name version := item.Chart.Metadata.Version appVersion := item.Chart.AppVersion()- updated := strconv.FormatInt((item.Info.LastDeployed.Unix() * 1000), 10)+ updated := item.Info.LastDeployed.Unix() * 1000 namespace := item.Namespace status := statusCodeMap[item.Info.Status.String()] latestVersion := getLatestChartVersionFromHelm(item.Chart.Name(), config.HelmRegistries) //latestVersion := "3.1.8"- stats.WithLabelValues(chart, releaseName, version, appVersion, updated, namespace, latestVersion).Set(status)++ if *infoSeries == true {+ statsInfo.WithLabelValues(chart, releaseName, version, appVersion, strconv.FormatInt(updated, 10), namespace, latestVersion).Set(status)+ }+ if *timestampSeries == true {+ statsTimestamp.WithLabelValues(chart, releaseName, version, appVersion, strconv.FormatInt(updated, 10), namespace, latestVersion).Set(float64(updated))
ya, with my above suggestion making them optional would not really make sense. I think it would be best to have the existing one always one with statsTimestamp optional, but I'm also fine with how you have it now.
comment created time in 16 days
issue commentrxhanson/Rectangle
Remember window position per display
This currently bites me when unplugging my MacBook and then going back to closing the MacBook and reconnecting it to the display.
comment created time in a month
issue commentrxhanson/Rectangle
I came here to create this exact feature request. For a first round of customization could it be done with just a configuration file and no UI element if that makes it faster? I also run a ultrawide. I run it in thirds with the middle split into sixths.
Currently I place some windows in the first third and some windows in the last third. For the middle I drag them to the third and I shrink them either into the top 6th or the bottom 6th. Being able to customise this and have the middle selectively snap to 6ths would be fantastic.
comment created time in a month
push eventsstarcher/helm-exporter
commit sha 40ce6a2c5d22e1de67e9ac69ead22ba5f87796be
Ability to set additional Service annotations
push time in 2 months
pull request commentsstarcher/helm-exporter
Add option to set the value to helm release's timestamp
But it's not the same metric. I would recommend renaming it. One allows you to track the status of a release. The one you added allows you to track release events. My main use case is tracking the current and prior status of a release. With the current code if I enable your option to track events I can no longer track release statuses.
comment created time in 2 months
pull request commentsstarcher/helm-exporter
Export latestVersion in metrics which is available in upstream helm repo
Thanks for the contribution!
comment created time in 2 months
push eventsstarcher/helm-exporter
commit sha 4e8d4fc1ab300d199008a24a2332448cfd42372f
Export latestVersion in metrics which is available in upstream helm repo (#37) Add code to check for latest helm version in upstream helm repo.
push time in 2 months
PR merged sstarcher/helm-exporter
The changes introduce the latestVersion label on the metrics. The upstream helm repo is check for the latest version. It is configurable which upstream repo should be used in case it's not the default. In case multiple charts with the same name are found the config can specify the exact one. The code is basically ported and adjusted from this repository https://github.com/arminc/k8s-platform-lcm The credits therefore go to @arminc
Last remark: I'm not absolutely sure if the MIT license would need to be added to this repository and of course whether or not you want this. According to this thread MIT code and be copied into Apache licensed code https://law.stackexchange.com/questions/6081/can-i-bundle-mit-licensed-components-in-a-apache-2-0-licensed-project#:~:text=Both%20the%20Apache%20License%20and,licensed%20project%20is%20certainly%20allowed.&text=The%20MIT%20license%20is%20a,license%20you%20can%20think%20of..
pr closed time in 2 months
pull request commenthelm/charts
[stable/filebeat] introduce dnsConfig values for the containers
@orong-pp I don't have any control over that.
@rendhalver Do you have any plans to move this out of the helm/charts repo as this will go away Nov 2020.
I have a setup and projects outside of this org if you don't have any intentions to I would be more than happy to manage it.
comment created time in 2 months
pull request commenthelm/charts
[stable/filebeat] introduce dnsConfig values for the containers
/ok-to-test
comment created time in 2 months
pull request commentsstarcher/helm-exporter
Export latestVersion in metrics which is available in upstream helm repo
Nope, you are correct and I'm mistaken. As you have pointed out the gain is minimal. It would be a slight gain as you would not the cardinally of a 8 label metric vs a 1 label metric, but I do agree I doubt that's really something we should consider.
The only thought would be if we would want to separate it out as incase we keep adding extra information.
- release
- chart
comment created time in 2 months
pull request commentsstarcher/helm-exporter
Export latestVersion in metrics which is available in upstream helm repo
It would greatly reduce the cardinality in a few ways.
- Moving it to a separate metric would allow you to use the latest not as a label, but as a value which would mean the cardinality is 1 vs N(every change to the version)
- Separating it would would also stop us from reducing the carindality of the current metric. Anytime the version would get updated or any syncs etc you would have yet another increase in cardinality.
Overall not saying that the increase in cardinality is ground breaking, but I think it would make sense to separate it out as the "latest" version is more an object of the chart repo vs the current metrics are metrics of a specific release.
As long as the release metric has the chart name and the latest metric has the chart name label you should be able to link them together if wanted.
comment created time in 2 months
pull request commentsstarcher/helm-exporter
Export latestVersion in metrics which is available in upstream helm repo
Thanks these changes are interesting. I currently have two main questions.
- Some of this code looks like we could use the helm libraries themselves.
- Would it make sense to split this out as it's own metric to lower the cardinality of our metrics?
comment created time in 2 months
push eventsstarcher/sstarcher.github.io
commit sha 4d17fe5eb69582f4834dabec92b49dbab7e76859
Site updated at 2020-06-06 00:40:14 UTC
push time in 2 months
push eventsstarcher/sstarcher.github.io
commit sha 2cc45352f12e25be562de5930d6263934cccb0d8
updates
push time in 2 months
push eventsstarcher/sstarcher.github.io
commit sha 88bf00712ec3125cee0b36585fcb8826ea2b5360
fixing recipe
push time in 2 months
push eventsstarcher/sstarcher.github.io
commit sha f1d66eac29aa0670018649da4674dfafd6fd6144
Site updated at 2020-05-29 21:33:01 UTC
push time in 2 months
pull request commentjupyterhub/kubespawner
support internal_ssl for kubespawner
@manics I don't know if I agree with that assessment. This PR handles TLS communication for kubespawner pods. You don't need E2E TLS for all of JupyterHub for TLS for this to be verified.
comment created time in 2 months
PR closed jupyterhub/kubespawner
Here is my attempt at adding ssl support to Kubespawner.
https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/1520
pr closed time in 2 months
pull request commentjupyterhub/kubespawner
support internal_ssl for kubespawner
Anyone is free to take this over. If you have any limited changes you want me to make I can probably do that, but I will no longer have time for any more in-depth changes.
comment created time in 2 months
PR closed jupyterhub/zero-to-jupyterhub-k8s
Resolves #1520 this will need to wait until my PR into KubeSpawner is also released. https://github.com/jupyterhub/kubespawner/pull/386
pr closed time in 2 months
issue closedsstarcher/helm-release
Documentation missing -s option
Dear,
referring to
this
the option -s is not documented in Readme usage.
So
helm release CHART - Would determine the next tag for the chart and update the Chart.yaml
is not true. Without passsing the -s flag it will update both Chart and values.
Thanks,
Ivan
closed time in 3 months
iosdal
issue commentsstarcher/helm-release
Documentation missing -s option
Thanks, does this fix it properly - https://github.com/sstarcher/helm-release/commit/a2f4cd07966da2a485a1f7a5e862465740c7b81b
comment created time in 3 months
push eventsstarcher/helm-release
commit sha a2f4cd07966da2a485a1f7a5e862465740c7b81b
Update README.md
push time in 3 months
pull request commentsstarcher/helm-exporter
Add option to set the value to helm release's timestamp
Excellent that's a great idea. So with your PR we have two modes.
- Metrics collected where the value is the status. This allows you to graph the health of a release.
- Metrics where the value is the timestamp. This allows you to put events onto nodes.
Would it make sense to not make them mutually exclusive? Maybe a default mode where metrics for both get generated and a flag to turn each of them off separately?
comment created time in 3 months
push eventsstarcher/helm-charts
commit sha bb46c281c593957aad6753a745f12be7212dc2bb
add chart for sstarcher/newrelic-operator
push time in 3 months
created tagsstarcher/newrelic-operator
Kubernetes Operator for managing New Relic resources
created time in 3 months
push eventsstarcher/newrelic-operator
commit sha f2ca80378558434936daef320dd8c8cb71584a68
Fix CRD spec to allow for floats in `spec.slaThreshold`
push time in 3 months
PR merged sstarcher/newrelic-operator
Guessing this became an issue when we updated the k8s version, not super sure.
Working on:
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}
pr closed time in 3 months
pull request commentjupyterhub/kubespawner
support internal_ssl for kubespawner
I have approx 2 weeks to get any additional changes merged. Afterward, I will likely not have any more time to work on this PR for months. Let me know what I can do to assist.
comment created time in 3 months
Pull request review commentjupyterhub/kubespawner
support internal_ssl for kubespawner
def _start(self): pod = yield gen.maybe_future(self.modify_pod_hook(self, pod)) for i in range(retry_times): try:- yield self.asynchronize(+ created_pod = yield self.asynchronize(
My experience was that the object returned without the UID.
comment created time in 3 months
push eventsstarcher/kubespawner
commit sha 7491d5cb8dee647aa43ac1875012e435bfabe52e
fixup! fixup! fixup! fixup! fixup! fixup! fixes
push time in 3 months
push eventsstarcher/kubespawner
commit sha 42321ad70227e8432c960777659bd2a2c0be7f18
fixup! fixup! fixup! fixup! fixup! fixes
push time in 3 months
push eventsstarcher/kubespawner
commit sha 65a117b5c6a907cf56021774cb7e04d72481e662
fixup! fixup! fixup! fixup! fixes
push time in 3 months
push eventsstarcher/kubespawner
commit sha 438ae18d35468931d2c7466a151a692b1483dd73
Test JupyterHub's master branch
commit sha b47e7db3dd883ba6de2770ff32d545e7e016aeb5
Typos in storage capacity docstring.
commit sha 5a9651c4f30d9ae96676937af1ac0e8082e6c4ed
log a warning if unrecognized user_options are provided should help debugging if folks aren't seeing the effects they expect
commit sha 180b3a629b235855499f964b524b289b434f0d9e
Update contributing guide
commit sha 91f6592b5cdec0b1512edab1b6e17ca083d2d8bf
Fix typos
commit sha d9d3472e8bad9483bc2d0b5022b0b22d6c91c1b3
log a warning if unrecognized user_options are provided (#389) log a warning if unrecognized user_options are provided
commit sha 892780ae86c6e74172065ab984bf2d059d00c31f
Typos in storage capacity docstring. (#384) Typos in storage capacity docstring.
commit sha 63ef7bbb54071a7dd6bc439642c1490941474913
Update default k8s and minikube version
commit sha cc5ef9e8dc1827240cce4c698629e9c972d1e5ad
xenial for k8s 1.13 test and test k8s 1.17
commit sha 23b6453ebd2ef9db88ae25415a07d578df8954ed
Add notes about xenial
commit sha fb1de7a692f3ed724cbb6741852d89041ba6869a
Merge pull request #394 from consideRatio/resolve-ci-issue Fix CI build error
commit sha c49d55f9dd2831914f63651aa44fcc0fe3b2d3d6
Add linux command to remove a route
commit sha 86f1a0c2847e8ad874864efca95603ee9efc2b84
Merge pull request #391 from betatim/dev-docs [MRG] Update contributing guide
commit sha 8751773916ccc6b84c998f7950dd3e07fea5ae4e
Merge pull request #380 from consideRatio/test-jupyterhub-master Test JupyterHub's master branch
commit sha 382514282caec4cf6204add5247308e23b90c07f
Update Ingress model imports for python-kubernetes>=10.0
commit sha 39fefa912c7a0dcb495aa977d5179c0727542d75
Stick to ExtensionsV1beta1 for now to keep compatibility with K8s < 1.18
commit sha 1a28e45945281b526cd9d68d0027c999d750573a
Add test for make_ingress() and its return values
commit sha 96a06740562372561ce5e2035cbc3eb83e8ad38a
Bump pytest required version to 5.4
commit sha 3d9519ba2c1894a4a8f5e6b211fa92c12fcdb78d
Fallback to old imports to retain backwards compatiblity
commit sha 956a12d2cf2524fdbf5ca88720dc7323a30dce66
Merge pull request #402 from BertR/update_ingress_models
push time in 3 months
push eventsstarcher/kubespawner
commit sha aa8c3a2e57096b365381f5bf7d10718b9183c8b0
fixup! fixup! fixup! fixes
push time in 3 months
pull request commentjupyterhub/kubespawner
support internal_ssl for kubespawner
Let me know if I can do anything else to move this forward we have been using it in production for months.
comment created time in 3 months
issue commentzendesk/helm-secrets
Looks like they are not responding. @szibis are you going to add collaborators for this or should we consider it a dead project?
comment created time in 3 months
pull request commentsstarcher/helm-exporter
Add option to set the value to helm release's timestamp
If changing the value to a time series what would you be graphing in grafana? Do you have an example of what you are trying to accomplish?
comment created time in 3 months