Inventor's Paradox

The freezing app problem When dealing with a freezing application, most management (or even management with IT background) will say it is related to capacity problem. Usually the capacity are correlated to how many processor core, how many gigabytes memory available to the system, and how much bandwidth are available. The reality is not that simple.  When an application freeze or slows down, it is to the best interest of the application team, whether operational, development, devops team, or service team (as it is said in the ITIL), to find out how to make it accessible again, and in management terms, increase the system's capacity. The first step to do that, is to actually determine the bottleneck, which traditionally is done by checking memory usage, CPU usage, and network link usage. But I am not thinking to make this a traditional post, so in this post I will try to describe other stuffs that could cause slowdown or freezing app problem. The APM way of things Today we have APM

 Background Sometimes, we need to override a single file in a pod without having to build a new image. There is a technique to do this, so this blog would serve to remind me of the steps involved doing just that. 1. Create A Configuration Map First we need to copy the original file to the notepad. The steps are : yudhi@Yudhis-MacBook-Pro ~ % oc project apifinance Now using project "apifinance" on server "https://lb.osh.telkom.co.id:8443". yudhi@Yudhis-MacBook-Pro ~ % oc get po NAME                     READY     STATUS       RESTARTS   AGE finance-2-chm5g         1/1       Running     0           211d finance-3-build         0/1       Completed   0           248d financeapi-46-8wmfh     1/1       Running     0           30d proxy-finest-10-1btmq   1/1       Running     0           58d yudhi@Yudhis-MacBook-Pro ~ % oc rsh proxy-finest-10-1btmq sh-4.4$ cd /etc/httpd sh-4.4$ ls conf   conf.d   conf.modules.d   logs   modules   run   state sh-4.4$ cd conf.d sh-4.4$ ls REA

Tracing PHP applications are typically done by putting echo statements in code path in a debug session. When PHP applications are deployed into openshift environment, the developer could edit the source code in development app (not production) to add echo statements. Typically this is done using the terminal. However the development experience is not very good. Background When debugging or tracing, we developers sometimes need to check multiple files at once, and sometimes need to do a project-wide search to find the source file containing one class or method. Most developers find this is not easy to do  in the terminal interface. They normally use editors such as Visual Studio Code to be able to search quickly and jump between source code files, and using vi in the terminal is somewhat off-putting. A better solution is to run Visual Studio Code remotely in the pod's container. How to Launch Visual Studio Code in Pods There are a few prerequisite needed to be able to launch visual

Overview Red Hat  has augmented docker's registry with some enhancement before deploying it in Openshift cluster. In some cases we might want to debug it, to find out reasons why some stuff doesn't work or for educational purposes. In this post we will describe steps required to do debugging for the docker registry (a.k.a docker distribution) from Visual Studio Code. We are going to run the openshift docker registry in a separate deployment config. Repository identification First, docker registry is created using Go Language; and in this case, the source code for the enhanced docker registry lives in github repository  https://github.com/openshift/origin for some versions and in  https://github.com/openshift/docker-distribution for later versions. In this post I will use the version in openshift 3.6 ( https://github.com/openshift/origin/tree/v3.6.1 ) because of selfish reasons our sandbox/development openshift cluster uses this version. The main source code file lives in cm

 Introduction I need to upgrade the installed OS in my Macbook Pro into Mac OS 12 Monterey, and after doing that, I just found out that the OC (oc) client no longer works. OC Client is Red Hat's replacement for kubectl, which should be used to connect to Openshift Kubernetes Clusters. The oc's versions should match the installed OKD (community) / OCP (enterprise) version, unless you want some strange errors showing. We could say than openshift is an improved kubernetes, and oc is an 'improved' kubectl.  The error yudhi@Yudhis-MacBook-Pro Downloads % oc fatal error: runtime: bsdthread_register error runtime stack: runtime.throw(0x3a97cf6, 0x21) /usr/local/go/src/runtime/panic.go:566 +0x95 fp=0x7ff7bfeff9d0 sp=0x7ff7bfeff9b0 runtime.goenvs() /usr/local/go/src/runtime/os_darwin.go:88 +0xa0 fp=0x7ff7bfeffa00 sp=0x7ff7bfeff9d0 runtime.schedinit() /usr/local/go/src/runtime/proc.go:450 +0x9c fp=0x7ff7bfeffa40 sp=0x7ff7bfeffa00 runtime.rt0_go(0x7ff7bfeffa70, 0x1, 0x7ff7bf