Kubernetes Pod refreshed along with ConfigMap

Typically an application's code will be running in a pod while its configuration stays in a ConfigMap. If the configuration is consumed as a file instead of a bunch of environment variables, it will be updated when the relevant ConfigMap changes. How should the application be notified then?

The application could always implement something like a "/reload" endpoint so that the new config is recognized. Another deployment pattern could also be considered as a common solution, which binds the ConfigMap to the pod and forces the update:

https://blog.questionable.services/article/kubernetes-deployments-configmap-change/


Update: Combined with a "/reload" endpoint, this provides a nice instrumenting sidecar for automatic reload of new configurations from ConfigMap volumes.

The business with Meta and Esc keys

On iTerm2 by default the Option key is mapped to, well, Option itself, as to type special symbols. That doesn't make much sense as in a terminal emulator you probably want to send keyboard shortcut signals rather than fancy signs.

Hence the remapping option of Left/Right Option keys to Meta or Esc+. But why not just Meta alone? Why does Esc have to do with anything?

It turns out that Meta and Esc are equivalent. But why the redundancy? I Googled quite a bit but findings are limited.

https://www.gnu.org/software/emacs/manual/html_node/emacs/User-Input.html states that "this feature is useful on certain text terminals where the <Meta> key does not function reliably".

https://books.google.com/books?id=P_jCDAAAQBAJ&pg=PA73 states that "this alternative way of using <Meta> was created because, at one time, there were keyboards that didn't have a Meta key or an Alt key".

http://ergoemacs.org/emacs/modernization_meta_key.html is also a good reference for you to understand that keyboards don't always look the way they do today.

At least one can finally make sense out of the redundancy. Relieved, right?

Setting non-standard shell as login shell

Bash that is shipped with macOS is pretty old, at least as of Mojave. If you've installed a modern version through Homebrew, you probably need to configure it as your login shell, to save you some troubles with Terminal, iTerm or tmux. This is the way:

sudo chsh -s $(which bash) $(whoami)

Rationale (especially the part how /etc/shells is not touched for sanity reasons):
https://superuser.com/a/48229

Update 2023: I guess history does repeat itself! I ran into this issue again the other day and totally had forgotten I had had this experience before and even the existence of this very blog post. I managed to figure it out from the man page though, which reads:

When altering a login shell, and not the super-user, the user may not change from a non-standard shell or to a non-standard shell. Non-standard is defined as a shell not found in /etc/shells.

Linux special permissions

I've always known the read/write/execute permission system, but been a bit vague on setuid/setgid or the sticky bit. So to set things straight once and for all, the following blog did the favour.

https://linuxconfig.org/how-to-use-special-permissions-the-setuid-setgid-and-sticky-bits

Inline file descriptor redirection of a bash script

If the title doesn't make any sense it's probably because I made that name up. But what I actually mean simply looks like this:

exec 1>$SOME_LOG_FILE

exec 2>&1

Ring a bell, huh?

Have known this tip for some time but have rarely used it. On a recent occasion I had to revisit it and digged a bit deeper, thanks to this great blog post that explained it thoroughly.

https://ops.tips/gists/redirect-all-outputs-of-a-bash-script-to-a-file/

A handy way of debugging Jinja2 templates

Came across this today. Instead of assembling a whole Ansible playbook and role structure to test out a Jinja2 template, you can just import the jinja2 module in the Python interactive interpreter and do your test. You don't even have to worry about installing the jinja2 module. You can run Ansible playbooks with template modules so it's already there, right?

Credit goes to this nice blog post - https://overiq.com/flask-101/basics-of-jinja-template-language/.