profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jutley/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Jake Utley jutley Hiya, Inc. Seattle

jutley/dynamodb-helm-chart 1

A Helm chart for DynamoDB, including bootstrapping tables and rows

jutley/argo-cd 0

Declarative continuous deployment for Kubernetes.

jutley/argocd-notifications 0

Notifications for Argo CD

jutley/aws-sso-util 0

Smooth out the rough edges of AWS SSO (temporarily, until AWS makes it better).

jutley/blackbox_exporter 0

Blackbox prober exporter

jutley/cortextool 0

A powerful command line tool for interacting with cortex

jutley/etcd 0

Distributed reliable key-value store for the most critical data of a distributed system

jutley/go-version 0

Golang Cobra & Goreleaser Versioning library

issue commentkubernetes/kubectl

`kubectl config set-credentials` should support impersonations fields

Is there any documentation on how to use kubectl config set? I can't find any, and am trying to use it to construct my config from scratch. I can't seem to set any exec values for my user.

➜  k config set users.oidc.exec.command foo
error: unable to parse one or more field values of users.oidc.exec.command
jutley

comment created time in 3 days

issue commentargoproj/argo-cd

Option to perform K8s v1.16 server-side apply

I'd love to see Argo CD support server-side apply.

We have a use case I don't see discussed much. We leverage mutating webhooks to provide lots of valuable default configuration for our Kubernetes users. An issue with this is that when running kubectl apply, the mutation will not take place if there is no difference between the desired and live states (I believe kubectl doesn't try to apply the patch in this case). However, when running kubectl apply --server-side, the mutations are always applied.

Our users primarily interact with Kubernetes through ArgoCD. Without Argo CD supporting server-side apply, there is no way apply these mutations unless the resource actually has some new desired state.

jessesuen

comment created time in 3 days

issue openedargoproj/argo-cd

Allow viewing previous container logs in log viewer

Summary

When using kubectl logs, we have the flag --previous available, which allows us to view the logs of the previous container before it stopped running, which may have been due to a crash or a successful completion. This functionality is not currently available in the Argo CD logs view, and would be a nice addition.

Motivation

Many of our users are almost exclusively using Argo CD as their Kubernetes interface, opting to use kubectl only when necessary. kubectl logs --previous is one of the scenarios when they need to switch over to using kubectl.

Proposal

The buttons at the top of the logs can be updated to include a new toggle that corresponds to the --previous flag.

created time in 9 days

issue openedargoproj/argo-cd

Cmd+Click on multiple applications opens each application in the same browser tab

Checklist:

  • [x] I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq.
  • [x] I've included steps to reproduce the bug.
  • [x] I've pasted the output of argocd version.

Describe the bug

When I cmd+click multiple applications, a new browser tab is opened for the first application, but each successive application opens in the same browser tab as the first application. Typically, a cmd+click always opens in a brand new tab, and in the case of Argo CD we often want to view multiple applications to compare. The current functionality is surprising and makes this difficult.

To Reproduce

A list of the steps required to reproduce the issue. Best of all, give us the URL to a repository that exhibits this issue.

  1. Go to https://cd.apps.argoproj.io/applications
  2. Cmd+click any application to open it in a new tab
  3. Go back to the previous tab which lists all applications
  4. Cmd+click a different application than in step 2
  5. The new application is loaded in the tab from step 2

Expected behavior

I would expect multiple cmd+click actions to open each application in its own tab.

Version

We are currently running v2.0.4+0842d44, though this is also true of the demo Argo CD, which is currently running `v2.2.0+fc49eb2.

created time in 9 days

issue commentargoproj/argo-cd

Add k8s labels to argocd_app_info metric

Found this ticket from wanting behavior like this. My recommendation would be to make a separate metric argocd_app_labels in the same spirit as kube-state-metrics' kube_pod_labels.

Regarding cardinality, I would argue that this is not an issue. Typically cardinality concerns have to do with having many possible values for multiple labels, and having metrics express all the possible combinations of these. This concern is not applicable to metrics that represent kube labels, because there is exactly one such metric for each kubernetes resource. There is no fanning out.

I think most orgs that run both Kubernetes and Prometheus are using kube-state-metrics, and there are many info metrics that expose resource labels. Given that one ArgoCD application creates many Kubernetes resources, we are surely going to see fewer of these argocd_app_label metrics than what kube-state-metrics exposes.

snuggie12

comment created time in 10 days

issue commentprometheus/alertmanager

Send resolved notification for silenced alerts

Silence should be tied to the current state of the alert and not to the alert, IMO.

I think this is getting at the core of the issue. My team consistently finds ourselves having to manually resolve alerts that are no longer firing simply because Alertmanager's silences are way too simple. In our case, we would like silences to prevent notifications when new alerts come up, but allow notifications when alerts transition to resolved. If silences were augmented to allow us (either the silence creator or Alertmanager operator) to select specific state transitions, this would completely solve the problem for us.

I cannot count the number of times I have had to explain to our engineers why they are still being alerted on something that has resolved. After the explanation, there is always a shared consensus that Alertmanager is doing it wrong.

fabxc

comment created time in 15 days

issue closedhiyainc-oss/jenkins-stateful-agents-demo

are there any updates about this project

hi @jutley @kiyose, I just found your blog post and this solution. and i'm now facing similar challenges. and considering similar alternatives. have anything changed in your solution? what would you have done today?

closed time in 15 days

nahum-litvin-hs

issue openedkubernetes/kubectl

`kubectl config set-credentials` should support impersonations fields

<!-- Please only use this template for submitting enhancement requests -->

What would you like to be added: The AuthInfo struct contains fields Impersonate, ImpersonateGroups, and ImpersonateUserExtra, which are defined in YAML with the fields as, asGroups, and asUserExtra (not sure on the casing). The kubectl config set-credentials should allow us to set these fields, as it allows for every other field.

Why is this needed: Most, if not all other fields are able to be defined with kubectl config set-credentials. This enhancement works towards completeness, and also allows users to fully configure their kubeconfig without having to use additional utilities.

created time in 16 days

push eventhiyainc-oss/hw

Jake Utley

commit sha 3658807bdd0007a147f50220368b9796ba995cb5

Revert "Remove GITHUB_TOKEN from testing steps" This reverts commit 8e07e6a8b6222116f26a7a3b6f15859eade89044.

view details

push time in 24 days

delete tag hiyainc-oss/hw

delete tag : v0.0.11-1

delete time in 24 days

delete tag hiyainc-oss/hw

delete tag : v0.0.11-2

delete time in 24 days

push eventhiyainc-oss/hw

Jake Utley

commit sha 8e07e6a8b6222116f26a7a3b6f15859eade89044

Remove GITHUB_TOKEN from testing steps

view details

push time in 24 days

PR opened hiyainc-oss/hw

Use GitHub packages instead of bintray
+18 -49

0 comment

3 changed files

pr created time in 24 days

push eventhiyainc-oss/hw

Jake Utley

commit sha 964ef6d822faba038882f0374be46dee887e742b

Remove dead code and switch back to releasing on master branch

view details

push time in 24 days

created taghiyainc-oss/hw

tagv0.0.11-2

Hello world in Scala

created time in 24 days

push eventhiyainc-oss/hw

Jake Utley

commit sha cbabbcc51ed374cca2fd97c9b583f97d991558de

gh release only on 2.13

view details

push time in 24 days

created taghiyainc-oss/hw

tagv0.0.11-1

Hello world in Scala

created time in 24 days

create barnchhiyainc-oss/hw

branch : github-packages

created branch time in 24 days

delete tag hiyainc-oss/hw

delete tag : refs/heads/github-packages

delete time in 24 days

delete branch hiyainc-oss/hw

delete branch : github-packages

delete time in 24 days

created taghiyainc-oss/hw

tagv0.0.11

Hello world in Scala

created time in 24 days

push eventhiyainc-oss/hw

Jake Utley

commit sha 12abb407c6c0d82706d5ea207f2d94de6dae2233

Fix syntax issue

view details

push time in 24 days

push eventhiyainc-oss/hw

Jake Utley

commit sha c4114b3127eb57796b5592b7bcaf4ee4fda1bebc

Comment out release step

view details

push time in 24 days

push eventhiyainc-oss/hw

Jake Utley

commit sha 8d50497df3c7db459e5b2ebc7e01095336927443

Update workflow to set github api key in all sbt steps

view details

push time in 24 days

create barnchhiyainc-oss/hw

branch : github-packages

created branch time in 24 days

issue commenthiyainc-oss/jenkins-stateful-agents-demo

are there any updates about this project

We moved off of the pattern described by this blog post. First, we started using the standard k8s plugin for dynamic Jenkins agent pods. We used an EFS volume which could be used across pods, and let each job use a directory within that volume. More recently we scrapped all of our Jenkins work and moved to GitHub Actions. Using a hosted solution has been significantly simpler for us, and has let us focus our time on more important efforts.

nahum-litvin-hs

comment created time in 24 days

issue openedargoproj/argo-cd

Add a metric to express connection status to each cluster

Motivation

In the past, we have occasionally made misconfigurations that caused ArgoCD to get disconnected from some clusters. This is easy to detect if we manually check for the connectivity, but this isn't a task we would do under normal circumstances. To enable proactive fixing of this issue, we would like to have a metric for ArgoCD's cluster connectivity which we can alert on.

Proposal

Adding a metric like this (probably in the application controller) would be sufficient.

argocd_cluster_connection_status{server="https://kubernetes....",name="my-cluster",version="1.21"} == 1

created time in 2 months

issue commentkubernetes-sigs/aws-load-balancer-controller

Prometheus support

It looks like there are Prometheus metrics, but they do not expose any data on a per-ingress or per-service level. Furthermore, there is not any data in the ingress itself that indicates that there may be an issue.

In the previous alb-ingress-controller, there was a metric called aws_alb_ingress_controller_errors{ingress="<namespace>/<name>"}, and we could use this to help notify teams that their ingress was misconfigured.

With the current metrics, we can only alert that something is failing to reconcile, and we are required to parse logs to understand the specific issue.

This is a pretty major usability issue.

runningman84

comment created time in 2 months

issue commentkubecost/cost-analyzer-helm-chart

Add custom athena workgroup support

I would like to specify a workgroup for kubecost so that I can keep its data and permissions completely separate from the rest of our Athena usage. By being forced to use the primary workgroup, we have to give kubecost access to any other query results using the primary workgroup. I think this is an important feature for information security.

korjek

comment created time in 2 months

push eventjutley/jutley

Jake Utley

commit sha f784184f753aaa1ac79754bb16d0977a452e1607

Update README.md

view details

push time in 3 months