dmitri-lerko

Extra verbosity to see underlying APIs:
kubectl --v=99 get pods busybox

Namespaces:
kubectl get ns
kubectl create ns linux
kubectl get ns/linux -o yaml
kubectl delete ns/linux

Specify PODs namespace:

dmitri-lerko

• Investigate this incident: what happened to cause this incident and why? Determining the root causes is your ultimate goal. Examples: logs analysis, diagramming the request path, reviewing headdumps
• Mitigate this incident: what immediate actions can we take to resolve and manage this specific event? Examples: rolling back, cherry-picking, pushing configs, communicating with affected users
• Repair damage from this incident: how can we resolve immediate or collateral damage from this incident? Examples: restoring data, fixing machines, removing traffic re-routes
• Detect future incidents: how can we the time to accurately detect a similar failure? Examples: monitoring, alerting, plausibility checks on input/output
• Mitigate future incidents: how can we decrease the severity and/or duration of future incidents like this? How can we reduce the percentage of users affected by this class of failure next time it happens? *Examples: graceful degradation, dropping non-critical resu

dmitri-lerko

#
# POD linkerd-web-54f586f959-6mjrt (1 of 1)
#
# HELP request_total Total count of HTTP requests.
# TYPE request_total counter
request_total{direction="inbound",tls="no_identity",no_tls_reason="not_provided_by_remote"} 1756
request_total{authority="linkerd-controller-api.linkerd.svc.cluster.local:8085",direction="outbound",dst_control_plane_ns="linkerd",dst_deployment="linkerd-controller",dst_namespace="linkerd",dst_pod="linkerd-controller-789b557586-4pmbb",dst_pod_template_hash="789b557586",dst_service="linkerd-controller-api",dst_serviceaccount="linkerd-controller",tls="true",server_id="linkerd-controller.linkerd.serviceaccount.identity.linkerd.cluster.local"} 536
request_total{authority="linkerd-controller-api.linkerd.svc.cluster.local:8085",direction="outbound",dst_control_plane_ns="linkerd",dst_deployment="linkerd-controller",dst_namespace="linkerd",dst_pod="linkerd-controller-789b557586-lwfvt",dst_pod_template_hash="789b557586",dst_service="linkerd-controller-api",dst_serviceaccount="linkerd-controller

dmitri-lerko

for bucket in $(gsutil ls  -p project_name); do gsutil label ch -l "bucket:$(echo $bucket | cut -c 6- | sed 's/.$//' | sed 's/\./_/g')" $bucket; done

dmitri-lerko

function onEdit(e) {

  var row = e.range.getRow();
  var col = e.range.getColumn();
  if(col === 2 && e.source.getActiveSheet().getName() === "help_requests") {
    if(e.source.getActiveSheet().getRange(row, 1).getValue() == "") {
      e.source.getActiveSheet().getRange(row, 1).setValue(new Date()); 
    }
  }
}

dmitri-lerko

# List of kube_*_labels metrics - not all of these are useful for alerting. 
# kube_certificatesigningrequest_labels
kube_certificatesigningrequest_labels * on (certificatesigningrequest) group_right(label_team) (
  ...insert expression here
)

# kube_cronjob_labels
kube_cronjob_labels * on (cronjob, namespace) group_right(label_team) (
  ...insert expression here
)

dmitri-lerko

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.