We need a swap fn()

def swap(a, i, j):
    a[i], a[j] = a[j], a[i]

selection sort: Grow the sorted subarray in the front

Our sorted subarray starts at index 0 and grows to n-1. At each instance, find the smallest element and swap element in place.

def selectionsort(a):
    for sorted_array_idx in range(0, len(a)):
        i = sorted_array_idx
        for j in range(i+1, len(a)):
            if a[j] < a[i]:
                i = j
        swap(a, i, j)

insertion sort: Being more clever about growing the sorted subarray from the front

At any element j, we loop from j to 0 while the loop invariant array[j] < array[j-1] continues to be true. When the invariant is false, the previous swap() puts element j in place in the sorted subarray.

def insertionsort(a):
    for i in range(1, len(array)):
        j = i
        while j > 0 and array[j] < array[j-1]:
            swap(a, j, j-1)
            j -= 1

bubblesort: Grow the sorted subarray at the back

For any element i, we can swap with i+1 if a[i] > a[i+1]. If we loop over an array and swap at each of these conditions, then the last element will be the array’s largest value.

def bubblesort(a):
  SORTED = False
  sorted_array_idx = len(a)-1

  while not SORTED:
    SORTED = True

    for i in range(0, sorted_array_idx):
      if a[i+1] < a[i]:
        swap(a, i, i+1)
        SORTED = False
    sorted_array_idx -= 1

Quicksort: find the absolute index of the first element

All the previous sorting algorithms depend on a sorted subarray index. This is the index we continue to swap until the correct value is in place.

Quicksort uses the unsorted part of an array to find the absolute final place of the sorted subarray index (now called a pivot index). Because the pivot index is in it’s final place. We recurse over the unsorted left/right subarrays.

def quicksort(a, start, end):
    if end <= start:
        return

    pivot_idx = start
    left = start+1
    right = end

    while right >= left:
        if a[left] > a[pivot_idx] 
            and a[right] < a[pivot_idx]:
                swap(a, i, j)
        if a[left] <= a[pivot_idx]:
            i += 1
        if a[right] >= a[pivot_idx]:
            j -= 1
    # this swap places the correct value of j
    # into the pivot index.
    swap(a, pivot_idx, j)

    quicksort(a, start, right-1)
    quicksort(a, right+1, end)

tldr

For each pre-existing resource run:

  kubectl annotate $OBJ meta.helm.sh/release-namespace=${NAMESPACE}
  kubectl annotate $OBJ meta.helm.sh/release-name=${RELEASE_NAME}
  kubectl label $OBJ app.kubernetes.io/managed-by=Helm

then run helm install or helm upgrade

Setting the stage

Let’s create an example deployment and service. Using kubernetes yaml. Then we will attempt to wrap these resources into a helm chart.

http-echo.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: http-echo
  labels:
    app: http-echo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: http-echo
  template:
    metadata:
      labels:
        app: http-echo
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo
        args:
        - "-text=success"
---
kind: Service
apiVersion: v1
metadata:
  name: echo-service
  labels:
    app: http-echo
spec:
  type: LoadBalancer
  selector:
    app: http-echo
  ports:
  # Default port used by the image
  - port: 5678

Apply and verify that everything works

kubectl apply -f http-echo.yaml
kubectl get pods,deployment,service -l app=http-echo

NAME                             READY   STATUS    RESTARTS   AGE
pod/http-echo-58c8855bc6-62zjv   1/1     Running   0          5m
pod/http-echo-58c8855bc6-rbgqm   1/1     Running   0          5m
pod/http-echo-58c8855bc6-vrd2d   1/1     Running   0          5m

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/http-echo   3/3     3            3           5m

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
service/echo-service   LoadBalancer   10.96.182.49   172.18.0.150

Wrapping in a helm chart

We can use a minimal Chart.yaml file for this example.

Chart.yaml

name: http-echo
version: 0.1.0

And setup a basic helm chart directory

http-echo/
├── Chart.yaml
└── templates
    └── http-echo.yaml

1 directory, 2 files

The problem is that all of the resources that are specified in templetes/http-echo.yaml already exist. When we try to install this chart via helm install http-echo http-echo/ we get met with:

Error: INSTALLATION FAILED: rendered manifests contain a resource 
that already exists. Unable to continue with install: Service 
"echo-service" in namespace "default" exists and cannot be 
imported into the current release: invalid ownership metadata; 
label validation error: missing key 
"app.kubernetes.io/managed-by": must be set to "Helm"; annotation
validation error: missing key "meta.helm.sh/release-name": must
be set to "http-echo"; annotation validation error: missing key
"meta.helm.sh/release-namespace": must be set to "default" 

Annotate and label existing resources

Each resource needs two annoations and a label to be adopted by Helm.

annotations

• meta.helm.sh/release-namespace
• meta.helm.sh/release-name

label

• app.kubernetes.io/managed-by

for OBJ in deployment/http-echo service/echo-service
do
  kubectl annotate $OBJ meta.helm.sh/release-namespace=default
  kubectl annotate $OBJ meta.helm.sh/release-name=http-echo
  kubectl label $OBJ app.kubernetes.io/managed-by=Helm
done

Run helm install --dry-run http-echo http-echo/ to show the error no longer exist; without actually installing the chart.

More Information

This doesn’t work with CRD objects

It does! You need to annotate/label the CRDs as usual. But then set --skip-crds. Most charts have a crd.create = false setting.

Can I see the code that makes this adopt thing work?

helm issue #7649

Minimal client setup

All you need is a rest.Config. The simplest way to generate one is using config.GetConfigOrDie() which will traverse usual locations of kubeconfig files (i.e. $HOME/.kube).

import (
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/client/config"
)

func main() {
    c, _ := client.New(config.GetConfigOrDie(), client.Options{})
}

Using the client

All CRUD operations are docuemnted on the client docs page. Depending on the call signature, we need up to three pieces:

• Object or ObjectList
• ObjectKey
• ListOptions

Where do objects come from

The canonical reference is the api repo. The Objects are in the types.go file of their respective API group.

As an example. The Nodes object are in core/v1 group, so the Nodes struct is in core/v1/types.go. And can be used as:

import (
    corev1 "k8s.io/api/core/v1"
)

func main() {
    node := &corev1.Node{}
}

Using ObjectKey

Get() takes an ObjectKey object. The ObjectKey is an indirection to the types.NamespacedName Object. This object can be generated on the fly as there are only two keys: Namespace and Name.

_ := client.Get(context.TODO(), client.ObjectKey{
    Name: "Name",
}, node)

Generating ListOptions

controller-runtime has a convienant way to construct ListOptions objects using MatchingLabels or MatchingFields. Both are string maps to strings, and makes it very simple to list objects with specific label or field values.

package main

import (
    "fmt"
    "context"

    corev1 "k8s.io/api/core/v1"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/client/config"
)


func main() {

    c, _ := client.New(config.GetConfigOrDie(), client.Options{})
    nodes := &corev1.NodeList{}
    filter := client.MatchingLabels{
        "node-role.kubernetes.io/control-plane": ""
        }

    _ = c.List(context.TODO(), nodes, filter)

    for _, node := range nodes.Items {
        fmt.Println(node.ObjectMeta.GetName())
    }
}

tldr

Set your chrome options user-data-dir and profile-directory to a local directory under your control to persist SSO/sessions across script runs.

import os
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

home_dir = os.getenv('HOME')
profile_dir = home_dir + '/.local/share/chrome/profile'

chrome_options = Options()
chrome_options.add_argument(r'user-data-dir=' + profile_dir)
chrome_options.add_argument(r'profile-directory=Automation')

driver = webdriver.Chrome(options=chrome_options)

# do some driver/DOM automation
driver.close()

A simple view of chrome profiles

The profile path is where chrome saves passwords, sessions, history, etc.

Building a profile for autmation scripts

We can build a chrome profile for chromedriver and selenium to (re-)use generated session tokens, etc.

import os
from selenium.webdriver.chrome.options import Options

home_dir = os.getenv('HOME')
profile_dir = home_dir + '/.local/share/chrome/profile'

chrome_options = Options()
chrome_options.add_argument(r'user-data-dir=' + profile_dir)
chrome_options.add_argument(r'profile-directory=Automation')

This setups a profile directory at ./local/share/chrome/profile in our home directory. Ideally, you can make this directory more dynamic based on your needs. Check out XDG Base Directory Specs for some cross-platform inspiration.

Using our profile with our chromedriver

from selenium import webdriver

driver = webdriver.Chrome(options=chrome_options)

# do some driver/DOM automation

driver.close()

Why can’t we use my normal chrome profile

Unfortunately, as far as I can tell, two chrome processes can’t use the same profile at the same time. Furthermore, having chromedriver/selenium use your regular chrome profile can cause problems. I made one of my profiles unusuable trying to do this.

Debugging Notes

If SSO/Sessions do not seem to persist across python script runs. A simple way to check that the profile path is correct is to not close the driver automatically. And visit chrome://version in the spawned chrome window.