hemantkashniyal

/**
 * Will generate versionCode from versionName that follows Semantic Versioning 
 */
ext {
    /**
     * Application version is located version variable.
     * And should follow next policy:
     * X1.X2.X3-type-flavor, where X - any digits and type is optional alphabetical suffix.
     * X1 - major version
     * X2 - minor version

hemantkashniyal

Kubectl output options

Let's look at some basic kubectl output options.

Our intention is to list nodes (with their AWS InstanceId) and Pods (sorted by node).

We can start with:

kubectl get no

hemantkashniyal

onServerStartup () {
  const { serverId, ip } = getServerInfo() // serverId does not change across restarts
  this.serverId = serverId

  // We don't have any routers or producers (yet). Clear any value that exists in the DB related to our serverId
  clearSharedDB(serverId, 'routers')
  clearSharedDB(serverId, 'producers')
  // Update the DB with our serverId and ip so that others will know how to reach us
  registerServerInDB(serverId, ip)
  

hemantkashniyal

Keybase proof

I hereby claim:

• I am hemantkashniyal on github.
• I am hemantkashniyal (https://keybase.io/hemantkashniyal) on keybase.
• I have a public key ASB0U4Ab2deqdxefv8aGieeBvFPu9Rs7BWHL6oEhmjQurgo

To claim this, I am signing this object:

hemantkashniyal

Multiplatform (amd64 and arm) Kubernetes cluster setup

The official guide for setting up Kubernetes using kubeadm works well for clusters of one architecture. But, the main problem that crops up is the kube-proxy image defaults to the architecture of the master node (where kubeadm was run in the first place).

This causes issues when arm nodes join the cluster, as they will try to execute the amd64 version of kube-proxy, and will fail.

It turns out that the pod running kube-proxy is configured using a DaemonSet. With a small edit to the configuration, it's possible to create multiple DaemonSets—one for each architecture.

Steps

Follow the instructions at https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ for setting up the master node. I've been using Weave Net as the network plugin; it see

hemantkashniyal

Multiplatform (amd64 and arm) Kubernetes cluster setup

The official guide for setting up Kubernetes using kubeadm works well for clusters of one architecture. But, the main problem that crops up is the kube-proxy image defaults to the architecture of the master node (where kubeadm was run in the first place).

This causes issues when arm nodes join the cluster, as they will try to execute the amd64 version of kube-proxy, and will fail.

It turns out that the pod running kube-proxy is configured using a DaemonSet. With a small edit to the configuration, it's possible to create multiple DaemonSets—one for each architecture.

Steps

Follow the instructions at https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/ for setting up the master node. I've been using Weave Net as the network plugin; it see

hemantkashniyal

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

1. Clarify and agree on the scope of the system

• User cases (description of sequences of events that, taken together, lead to a system doing something useful)
  • Who is going to use it?
  • How are they going to use it?

hemantkashniyal

Git

Global Settings

• Related Setup: https://gist.github.com/hofmannsven/6814278
• Related Pro Tips: https://ochronus.com/git-tips-from-the-trenches/
• Interactive Beginners Tutorial: http://try.github.io/
• Git Cheatsheet by GitHub: https://services.github.com/on-demand/downloads/github-git-cheat-sheet/

Reminder

Press minus + shift + s and return to chop/fold long lines!

hemantkashniyal

git stash list

• Lists all stashes on stack.

git stash apply stash@{0}

• Applies the changes from stash but does not delete from stack.

git stash pop stash@{3}

• Applies the changes from stash and deletes from the stack.

git stash show stash@{2}