My Blog

A New Journey

2022-06-15T00:00:00+00:00

For the past year or so, my wife and I have slowly been piecing together a plan to upend our lives (in a good way!) and commit to some radical changes. We've already been homeschooling our two children, and with our older child eligible for free national park admission for the next year, we've decided to take our family on the road, and try road schooling, starting this fall (2022).

This has some immediate side effects!

Home?</h1>
We've sold our home! Our new home is going to be a "rig", composed of a pick-up truck and an RV trailer, which we will be living in full time for the foreseeable future! We're ironing out the details, and I'll post more pics when I can.

Job?</h1>
Part of the planning has been the recognition that my current position as Director of Software Engineering at Crossover Health</a> is not one that would fit well with our travel lifestyle. In particular, we'll be traveling often mid-week, I'll be helping with home schooling more, etc. Trying to maintain my current role would be incredibly stressful, and I would not feel like I was doing my best work, and that would really hurt my need for integrity.
As such, I've had to do the right, but sad, thing, which was to give notice to my amazing boss, Ben, and the rest of my team, that I'll be stepping away from the Crossover family at the end of July.
I've had an amazing time building out the engineering team the past 5+ years, from me and two other engineers, to a team over 35+ folks, all of which I've been incredibly grateful to have had an opportunity to work with. I will miss them all, and am looking forward to staying in touch.
ZMK</h1>
The other huge change, is that as the door closes on my time at Crossover, a new door opens for me to have time to focus on ZMK</a> and keyboard design while we travel! Instead of trying to take on part time or contract work doing healthcare software, or other backend API work as I might have in the past, my intention is to devote that time to ZMK.
I am really excited for this. Full stop.
So Much To Do</h2>
So far, in the 2+ years working on ZMK, we've done a lot:
Initial work</a> to create the core keymap infrastructure, basic encoders, user config repos, and basic mod-taps</li>
Adoption and evolution</a> got us to a usable system, with BLE profiles, generic hold-taps.</li>
Keymap/HID refinements, Implicit Modifiers, Power Management</a></li>
Combos, Sticky Keys, Initial Display Support, Misc. Fixes</a></li>
Caps Word, Macros, Tap Dance, Split Locality for RGB/Power Control</a></li> </ul>
My goal is to be able to build upon the amazing core we have so far and keep going! Some things already have work/PRs I want to review and merge, others need me to stay heads and down and add code:

Encoders/sensors for split peripherals</li>
Fix the few lingering display issues to make them officially supported</li>
More powerful power management, including for connected peripheral hardware</li>
Simpler BLE profile management</li>
Multiple peripheral support (dongle mode!)</li>
RGB animations, and per-key RGB</li>
ZMK Studio, to make runtime keymaps a thing!</li>
Consistent PR review of contributions from others (our PR backlog is painful right now)</li> </ul>
In order to achieve this focus, I will be working towards trying to be financially supported by my work on ZMK. This is a huge change.
Aside: Open Source Sustainability</h2> In the wake of the log4j vulnerabilities, there was a renewed</a> focus</a> on open source sustainability</a>. This is not a new issue, but one that is getting more attention only thanks to an unfortunate set of reported security vulnerabilities.
I am a firm believer in open source, but my experience with open source and money are less than stellar. My previous employment at an "open source company" was mixed: the company itself is still going, but the 'open source' part of that was a dud.
There are a lot of different business models</a> for open source work. For something like ZMK, which does not have a copyleft</a> license, the options up for consideration really break down in to two major categories:
Non-OSS Work Funds OSS Work</h3>
Some example models that fit this:

Sell commercial support/consulting/services based on the OSS project.</li>
Commercial product built on open source core.</li>
"Freemium" model where additional features are made available for a price.</li> </ul>
Directly Funding OSS Work</h3>
This includes approaches like:

Direct sponsorship/patronage by users/companies.</li>
Bounties on bugs/features</li> </ul>
Getting Paid To Do What I Love?</h2>
As I imagined how I might want to approach this, a set of priorities stuck out:

I desperately want not to break the trust that I have earned with the community, who so far have relied on ZMK not having financial interests influencing it (or me, given my role as the creator and lead)</li>
I want the time spent on ZMK to broadly benefit the project and the community as a whole, not one particular user or company leveraging ZMK.</li> </ol>
Put another way:

Transparency in the process, direction, and funding is key,</li>
Money can mean influence; what I focus on, where I spend my time, etc.</li> </ol>
From those funding options I discussed above, this is what I've settled on:

Direct sponsorship/patronage, with no constraints on what I spend my time on.</li>
A selection of services I offer for a fee, i.e. contract work, which can be split into sub-categories:

Paid work on specific open source features</li>
Paid work on new open source drivers</li>
Paid work on "board bring up" for open source keyboards</li>
Paid work on "board bring up" for commercial/closed source keyboards</li> </ul> </li> </ul>
I am NOT going to:

Do a "freemium" model.</li>
Build some commercial product on top of ZMK.</li>
Do bounties on bugs/features</li> </ul>
Direct Sponsorship/Patronage</h3>
Ideally, the funds from this would be enough to support me and my family, and I can continue to generally contribute to the project, with as broad an impact as I can make. I am also realistic: getting my sponsorship to these levels may take time, or perhaps never happen. But given the advantages to sponsorship, I am going to keep working towards this as the end game.
To sponsor me, I've set up several sponsor tiers in GitHub Sponsors, named after various wireless standards: </iframe>
I've added some "perks" to those tiers, but none that are gate-keeping (you shouldn't have to sponsor me to see my plans, or access me via Discord, etc. See my previous note about transparency).
I would love to see companies that are leveraging ZMK recognize the value in this kind of contribution to my efforts, but also understand that might be harder for them to recognize the value in this kind of financial contribution. This might be especially difficult, given they've already been "getting my time for free" historically.
Given that, the second funding option will also be a part of the picture, at least as a gap measure:
Project Sponsorship Versus Personal</h3>
As some of you may know, ZMK already has sponsorship on Open Collective</a> for over a year. At no point have those funds been used to pay any individuals for their time/work on ZMK. Those funds are used for DNS name registration, other services, and most recently my work on ZMK Uno</a>, a development kit for ZMK.
ZMK project sponsorship isn't going to go anywhere. We will continue to find new ways to use the funds, e.g. making ZMK stickers, possibly paying legal fees to trademark certain terms, etc. I would encourage individuals and companies who are financially able to do so to continue donating there.
My personal sponsorship is just that, funding the work I specifically do for the project. For those individuals or companies who recognize the specific value I add to the project, I appreciate your sponsorship for that work.
Contract/Spec Work</h3>
Getting paid for specific work done on ZMK, or for keyboard using ZMK, is an obvious additional revenue source. The main downside to this funding source is the "influence" that such work plays on my time; every hour doing contract work for a specific user/company is an hour not spent on work of my choosing. There's certainly a chance that the contract work aligns with what I would choose to work on anyways. Ideally, I will be able to be selective with the contract work I take on, and favor work that aligns in this way.
To avoid any one company or contract having too much influence, there are a few mitigations I'm considering:

Spend a max percentage of my time any given month on a certain contract. 50%? 25%? Something to be evaluated.</li>
Bake "open source work of my choosing" into my contracts. This might be in the form of adjusting my bill rate for contract work to be "doubled" to cover time spent on other OSS work, or include hours baked into the contract that are for that OSS work.</li> </ol>
For now, to kick start this, I've created a selection of "one-time" options within GitHub Sponsorship for these, but you can also contact me directly if you are interested in something else/more specific.
The Future</h1>
I'm incredibly excited for this journey. I'm so thankful my wife and family are embarking on it with me.
I'm also thankful for all of the users and companies who have chosen ZMK, trusted me and our community to power their keyboards, and contributed to ZMK.
I can't wait to see what we can accomplish together in the future.

Cluster Triple - GitLab Runner

2020-01-26T00:00:00+00:00

In my previous post, I outline the Kubernetes setup</a> steps. Next up, I'm going install GitLab Runner via the standard helm chart. Beware: This was much harder than I hoped it would be!
Goals</h2>

Install GitLab Runner on the new Kubernetes Cluster running on the Cluster Triple + Base Pi.</li>
Add a job to a GitLab project that will be executed by our private runner.</li> </ol>
GitLab Runner Registration Token</h2>
In order to register a new GitLab Runner requires you use a registration token that is from either a certain GitLab project or a GitLab group that you are an owner of. For a certain project or group, you you can navigate to Settings » CI/CD and expand the *Runners section. From there, make a note of the registration token.
Installing the Helm Chart</h2> Installing Helm</h3>
If you don't already have Helm installed, check out the installtion options</a> to get the helm</code> CLI installed. I used Helm V3, although this should work fine with Helm V2 as well.
GitLab Chart Repo</h3> GitLab's helm charts can be found in their own Helm repository, so first we'll need to add the repo to your local setup:
$ helm repo add gitlab https://charts.gitlab.io/ "gitlab" has been added to your repositories </code></pre>
Helm Chart Values</h3>
To install the GitLab helm chart, there are some required configuration values that need to be passed. The full values.yaml</code> file that worked for me was the following:
image: petejohanson/gitlab-runner:latest gitlabUrl: https://gitlab.com/ runnerRegistrationToken: "m-FbJnAoZLeEf_q_3akE" runners: tags: "arm" runUntagged: false helpers: image: gitlab/gitlab-runner-helper:arm-latest rbac: create: true </code></pre> Let's break down those various values:

image</code> - The default gitlab-runner</code> Docker images is for x86_64</code>, not using the manifest behaviour that allows multi-platform images. See the PS at the end of this article for how this image was created, if you don't want to use the various I've built.</li>
gitlabUrl</code> - Since I'm registering this to the SAAS public GitLab instance, I'm using the normal GitLab URL.</li>
runnerRegistrationToken</code> - This is the registration token noted in the start of our process. This is a private/secret value.</li>
runners.tags</code> - Because I only want certain special jobs picked up by this runner, I've added the arm</code> tag to the runner.</li>
runners.runUntagged</code> - Same.</li>
runners.helpers.image</code> - This makes sure that the helper container that runs along-side the job containers using the version with the correct platform (Note: It would be nice if GitLab published images/tags using a manifest that pointed to the different architecture images properly)</li>
rbac.create</code> - Create the custom cluster role as part of the chart, since the runner needs to make calls into the Kubernetes API.</li> </ul>Install The Chart</h3>
We'll install the gitlab-runner</code> helm chart into a separate namespace, named gitlab-runner</code>, so we'll install the helm chart with the following:
$ helm -n gitlab-runner install -f values.yaml gitlab-runner gitlab/gitlab-runner </code></pre> Once that completes, you can check on the status of the running by listing the pods in that new gitlab-runner</code> namespace:$ kubectl get pods -n gitlab-runner NAME READY STATUS RESTARTS AGE gitlab-runner-gitlab-runner-f7d9cb88b-bhxc5 1/1 Running 0 6m13s </code></pre> Once the runner has a status of Running</code>, you can refresh the CI/CD page in GitLab and see the runner registered, with a green icon to show it live/active. Running a Job</h2> Adding A Tag To A Job</h3> Since we registered our runner to not pick up untagged jobs, and added an arm</code> tag to our runner, to get a job picked up by the runner we'll need to add the same tag to a job in our project. The tags</code></a> setting for a job is an array of tags required to exist on the runner. Here's an example job: build:rust:arm: stage: build image: rust:1-slim tags: - arm script: - cargo build </code></pre> Note: Your job must use an image</code> that works on the ARM architecture. Most images in Docker Hub that are part of the "core library" are actually a manifest that points to different docker images for different architectures, so should work. Others, e.g. rustlang/nightly-slim</code> are only built for x86_64. Running</h3> Once you push a commit with that job definition, you can monitor your cluster for a new pod starting to run the job: $ kubectl get pods -n gitlab-runner NAME READY STATUS RESTARTS AGE gitlab-runner-gitlab-runner-f7d9cb88b-bhxc5 1/1 Running 0 6m13s runner-p1uajn7v-project-12786723-concurrent-09xbxs 0/2 ContainerCreating 0 37s </code></pre> You can see an example of a job</a> completed with the GitLab Runner on my Cluster Triple Kubernetes cluster. Summary</h2> Once I got the custom gitlab-runner</code> Docker image built, the final setup was really easy. With this configured, it should be very easy to build binaries or even Docker images that target the ARM architecture as part of your standard CI/CD pipeline. PS - Building the gitlab-runner</code> Docker image</h4> In order to make this work, I need to build the gitlab-runner</code> Docker image, but for the arm</code> architecture. To do this, I took the following steps: Installed qemu-system-arm</code> on my Linux laptop.</li> Used libvert/GNOME Boxes to create a Fedora 30 VM running on the ARM architecture.</li> Logged into a shell in the new ARM based Fedora VM.</li> Installed various Fedora packages for Go, buildah</code> to build Docker images, etc.</li> Checked out the gitlab-runer</code></a></li> Ran make build_simple</code> to build gitlab-runner</code> for ARM. This took a not inconsiderable amount of time.</li> Built dumb-init</code> and git-lfs</code> from their respective git repos, since banries for ARM weren't handy.</li> Copied the binaries for dumb-init</code>, git-lfs</code>, and GitLab Runner from out/binaries/gitlab-runer</code> into the dockerfiles/alpine/</code> directory from the gitlab-runner</code> repository.</li> Edit the dockerfiles/alpine/Dockerfile</code> to not fetch various files over HTTP, but copy from the local filesystem.</li> Run buildah bud --build-arg DOCKER_MACHINE_VERSION=0.16.2 -t petejohanson/gitlab-runner:latest .</code></li> Wait</li> Run buildah login docker.io</code> to log in with my Docker Hub credentials.</li> Do buildah push -D petejohanson/gitlab-runner:latest</code> to push the images.</li> Whew!</li> </ol>
Cluster Triple - k3s setup 2019-09-09T00:00:00+00:00 In my previous post, I did the hardware setup</a>. Next up, I'm going to get Kubernetes running! Goals</h2> Run CBRIDGE</code> controller Pi as the Kubernetes master node</li> Join the three CM devices in the Cluster Triple as nodes in the cluster</li> Verify working behaviour of Kubernetes, with run of a simple command in a pod in the cluster</li> Access the cluster from my local laptop device.</li> </ul> Kubernetes Distribution</h2> This year, Rancher Labs released a new project, called k3s</a> which is a lightweight, but still certified distribution of Kubernetes</a>, that is tailored for IoT, ARM, CI, etc uses where stock Kubernetes isn't as suitable. I haven't played with k3s</code> yet, so this is a perfect opportunity to do so! Control Node Install</h2> First, we'll run the standard k3s</code> install script on the controller Pi. This will get our controller Pi set up as a Kubernetes master, and leave the CM devices as worker nodes eventually: pi@cbridge$ curl -sfL https://get.k3s.io | sh - [INFO] Finding latest release [INFO] Using v0.8.1 as release [INFO] Downloading hash https://github.com/rancher/k3s/releases/download/v0.8.1/sha256sum-arm.txt [INFO] Downloading binary https://github.com/rancher/k3s/releases/download/v0.8.1/k3s-armhf [INFO] Verifying binary download [INFO] Installing k3s to /usr/local/bin/k3s [INFO] Creating /usr/local/bin/kubectl symlink to k3s [INFO] Creating /usr/local/bin/crictl symlink to k3s [INFO] Creating /usr/local/bin/ctr symlink to k3s [INFO] Creating killall script /usr/local/bin/k3s-killall.sh [INFO] Creating uninstall script /usr/local/bin/k3s-uninstall.sh [INFO] env: Creating environment file /etc/systemd/system/k3s.service.env [INFO] systemd: Creating service file /etc/systemd/system/k3s.service [INFO] systemd: Enabling k3s unit Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service. [INFO] systemd: Starting k3s </code></pre> Once completed, you can inspect the status of things: pi@cbridge$ sudo kubectl get nodes NAME STATUS ROLES AGE VERSION cbridge Ready master 91s v1.14.6-k3s.1 </code></pre> Joining CM Nodes</h2> In order to join your CM nodes to the cluster, you'll need two pieces of info: The IP address of your cbridge</code> controller node. Alternately, you could try using the mDNS local name, but I have not tested this.</li> The secret token that can be used to join the cluster. This can be found in /var/lib/rancher/k3s/server/node-token</code> on the controller.</li> </ol> With that information on hand, you can run this for your first node: pi@p5$ curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.10:6443 K3S_TOKEN="SOME_SECRET_TOKEN_VALUE:node:123" sh - [INFO] Finding latest release [INFO] Using v0.8.1 as release [INFO] Downloading hash https://github.com/rancher/k3s/releases/download/v0.8.1/sha256sum-arm.txt [INFO] Downloading binary https://github.com/rancher/k3s/releases/download/v0.8.1/k3s-armhf [INFO] Verifying binary download [INFO] Installing k3s to /usr/local/bin/k3s [INFO] Creating /usr/local/bin/kubectl symlink to k3s [INFO] Creating /usr/local/bin/crictl symlink to k3s [INFO] Creating /usr/local/bin/ctr symlink to k3s [INFO] Creating killall script /usr/local/bin/k3s-killall.sh [INFO] Creating uninstall script /usr/local/bin/k3s-agent-uninstall.sh [INFO] env: Creating environment file /etc/systemd/system/k3s-agent.service.env [INFO] systemd: Creating service file /etc/systemd/system/k3s-agent.service [INFO] systemd: Enabling k3s-agent unit Created symlink /etc/systemd/system/multi-user.target.wants/k3s-agent.service → /etc/systemd/system/k3s-agent.service. [INFO] systemd: Starting k3s-agent </code></pre> Checking the status on things from the control node: pi@cbridge$ sudo kubectl get nodes NAME STATUS ROLES AGE VERSION cbridge Ready master 24h v1.14.6-k3s.1 p5 NotReady worker 1s v1.14.6-k3s.1 </code></pre> You can see the worker node has joined the cluster, but isn't yet ready. Waiting a bit longer, the node should be fully ready: pi@cbridge$ sudo kubectl get nodes NAME STATUS ROLES AGE VERSION cbridge Ready master 24h v1.14.6-k3s.1 p5 Ready worker 2m19s v1.14.6-k3s.1 </code></pre> I can then repeat the same thing on the other CM nodes, to finally have the basic Kubernetes cluster up and running: pi@cbridge$ sudo kubectl get nodes NAME STATUS ROLES AGE VERSION cbridge Ready master 24h v1.14.6-k3s.1 p5 Ready worker 5m27s v1.14.6-k3s.1 p6 Ready worker 30s v1.14.6-k3s.1 p7 Ready worker 5s v1.14.6-k3s.1 </code></pre> Running test pod</h2> pi@cbridge$ sudo kubectl run -i --tty alpine --image=alpine -- /bin/ash kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead. If you don't see a command prompt, try pressing enter. / # </code></pre> Before exiting the prompt, I verified where the pod was running: pi@cbridge$ sudo kubectl describe pod alpine | grep "^Node:" Node: p5/192.168.1.208 </code></pre> Accessing the cluster</h2> If you want, you can continue to interact with the cluster by first SSH-ing into the cbridge</code> control node. However, often you'll want to interact with the cluster from your local machine. By default, the installed configuration file is only accessible by root on the controller node, so you'll need to cat the content of the file w/ sudo, then paste into a local file: pi@cbridge$ sudo cat /etc/rancher/k3s/k3s.yaml apiVersion: v1 clusters: - cluster: certificate-authority-data: NOTFORYOU== server: https://localhost:6443 name: default contexts: - context: cluster: default user: default name: default current-context: default kind: Config preferences: {} users: - name: default user: password: OMITTED username: admin </code></pre> Openning an editor on your local machine to open ~/.kube/pi-cluster-config</code> and paste in the content. Once pasted, edit the server</code> line to change localhost</code> to the IP of your cluster, e.g. server: https://192.168.1.10:6443</code>. k3s</code> by default names all the cluster, user, etc information as default</code>, which isn't very helpful locally, so you may also want to replace all instances of default</code> with pi-cluste</code> in the file as well. To make sure you pick up any existing Kubernetes configuration, as well as the new one, you'll want to update your $KUBECONFIG</code> variable. If you already have one set, you can do: export KUBECONFIG=$KUBECONFIG:~/.kube/pi-cluster-config </code></pre> If you don't have any existing value for $KUBECONFIG</code>, you can do: export KUBECONFIG=$HOME/.kube/config:$HOME/.kube/pi-cluster-config </code></pre> Once $KUBECONFIG</code> is set, you can view the merged config: kubectl config view </code></pre> Finally, you can confirm you can access the cluster by describing the master cbridge</code> node: $ kubectl describe node cbridge Name: cbridge Roles: master Labels: beta.kubernetes.io/arch=arm beta.kubernetes.io/os=linux kubernetes.io/arch=arm kubernetes.io/hostname=cbridge kubernetes.io/os=linux node-role.kubernetes.io/master=true Annotations: flannel.alpha.coreos.com/backend-data: {"VtepMAC":"0a:f8:e2:7e:94:5f"} flannel.alpha.coreos.com/backend-type: vxlan flannel.alpha.coreos.com/kube-subnet-manager: true flannel.alpha.coreos.com/public-ip: 192.168.1.10 node.alpha.kubernetes.io/ttl: 0 volumes.kubernetes.io/controller-managed-attach-detach: true CreationTimestamp: Sat, 07 Sep 2019 23:05:21 -0400 Taints: <none> Unschedulable: false Conditions: Type Status LastHeartbeatTime LastTransitionTime Reason Message ---- ------ ----------------- ------------------ ------ ------- MemoryPressure False Mon, 09 Sep 2019 10:03:52 -0400 Sat, 07 Sep 2019 23:05:20 -0400 KubeletHasSufficientMemory kubelet has sufficient memory available DiskPressure False Mon, 09 Sep 2019 10:03:52 -0400 Sat, 07 Sep 2019 23:05:20 -0400 KubeletHasNoDiskPressure kubelet has no disk pressure PIDPressure False Mon, 09 Sep 2019 10:03:52 -0400 Sat, 07 Sep 2019 23:05:20 -0400 KubeletHasSufficientPID kubelet has sufficient PID available Ready True Mon, 09 Sep 2019 10:03:52 -0400 Sat, 07 Sep 2019 23:05:32 -0400 KubeletReady kubelet is posting ready status. WARNING: CPU hardcapping unsupported Addresses: InternalIP: 192.168.1.10 Hostname: cbridge Capacity: cpu: 4 ephemeral-storage: 15025172Ki memory: 948308Ki pods: 110 Allocatable: cpu: 4 ephemeral-storage: 14616487311 memory: 948308Ki pods: 110 System Info: Machine ID: 3390eb2107964e7d9da093e8c1d17922 System UUID: 3390eb2107964e7d9da093e8c1d17922 Boot ID: 2a3b0c78-a1cd-4a6f-9381-a2faa199e3e8 Kernel Version: 4.19.66-v7+ OS Image: Raspbian GNU/Linux 10 (buster) Operating System: linux Architecture: arm Container Runtime Version: containerd://1.2.7-k3s1 Kubelet Version: v1.14.6-k3s.1 Kube-Proxy Version: v1.14.6-k3s.1 PodCIDR: 10.42.0.0/24 Non-terminated Pods: (3 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits AGE --------- ---- ------------ ---------- --------------- ------------- --- kube-system coredns-b7464766c-pbbr6 100m (2%) 0 (0%) 70Mi (7%) 170Mi (18%) 34h kube-system svclb-traefik-plckk 0 (0%) 0 (0%) 0 (0%) 0 (0%) 34h kube-system traefik-5c79b789c5-m2f77 0 (0%) 0 (0%) 0 (0%) 0 (0%) 34h Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits -------- -------- ------ cpu 100m (2%) 0 (0%) memory 70Mi (7%) 170Mi (18%) ephemeral-storage 0 (0%) 0 (0%) Events: <none> </code></pre> If you're happy, make sure to add the export for $KUBECONFIG</code> to your ~/.bashrc</code> so it is automatic in the future. Next Steps</h2> Next, I'll work in setting up things like Kubernetes Dashboard, Prometheus, etc! Cluster Triple - A new Kubernetes cluster attempt 2019-09-06T00:00:00+00:00 Cluster Triple Intro</h2> Since the original KubeHat Project</a> was suspended, and the Pimera Project</a> met with mixed results, I was excited to recently discover that the developer of the ClusterHAT</code> was working on a new effort to cluster Pi Compute Modules, under the umbrella of ClusterCTRL</code>, the first iteration of this being the Cluster Triple</a>, of which there are a few early betas available for developers to try. An order on Tindie for the board, and another order to PiShop.us, and lo and behold! ) The Hardware</h2> It's easy to see the Cluster Triple as an evolution of the original Cluster HAT. The new Cluster Triple swaps out the Pi Zeros for the more expensive, but much more powerful Raspberry Pi Compute Module hardware format. Everything from the CM1 to the most recent CM3+ are compatible. Like the ClusterHAT, the node Pi devices depend on the expansion board being connected to a "controller" device, to which the nodes will be exposed via USB Gadget mode to connect virtual serial consoless, and virtual ethernet devices that can either be bridged or NAT'd to the controller's network connection. Board Specs</h3> Onboard 4-port USB 2.0 hub</li> ClusterCTRL (I2C) USB interface allows individual control of Pi power, fan, LED, etc.</li> Programmable power on states for LED, Individual Pi Power, USBBOOT, etc.</li> Unpopulated pads for ClusterCTRL UART status (for debug)</li> </ul> Compute Modules</h3> I decided to go with the latest CM release, so I purchased three Compute Module 3+</a> boards. These boards come in Lite (no eMMC), and 8GB, 16GB, or 32GB eMMC varieties. For mine I purchased the 16GB versions. Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.2GHz</li> 1GB LPDDR2 SDRAM</li> 16GB eMMC Flash memory</li> </ul> Hardware Setup</h2> I assembled the CMs into the Cluster Triple board, attached the provided USB cable to the controller USB port and the USB</code> port on the board, then plugged a micro USB charger into the PWR</code> port on board. Software Setup</h2> The latest Cluster Triple Raspbian images have some key variations across two axes: The network for the nodes can be either bridged with the controller's network interface, or the controller can use NAT, and the nodes will only have local IPs internal to the private network behind the controller.</li> The CM devices can either boot using USBBOOT off the controller (with optional data storage on the eMMC flash, if not using the Lite version), or can boot off the included eMMC directly.</li> </ol> For my particular use case, where I want the nodes to get IPs on my local LAN so I can use Kubernetes NodePort exposing for services, etc. I am going to use the CBRIDGE</code> images, and boot directly off the eMMC with a full OS images on each CM. Controller OS</h2> Since I'm using the controller itself to flash the images to the CM nodes, I grabbed the individual CBRIDGE - Lite Controller</code> controller image from the Cluster HAT - Software Setup</a> page. Once you've downloaded the image, you can write it to the microSD card for the controller: $ dd if=ClusterCTRL-2019-07-10-lite-4-CBRIDGE.img of=/dev/mmcblk0 bs=4M conv=fsync </code></pre> If you need to use SSH to log into controller, you'll want to mount the boot partition and touch /boot/ssh</code>, to ensure it comes up when the controller starts. From there, you can add the card back to the controller, and plug in the combination of the controller Pi, and the Cluster Triple board. Once booted, you can use the mDNS name to SSH into the bridge controller: $ ssh pi@cbridge.local pi@cbridge.local's password: Linux cbridge 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Sep 6 04:33:42 2019 from 192.168.1.86 pi@cbridge:~ $ </code></pre> Initial status</h2> Once you log into the bridge controller, you can see the status of the Cluster Triple by running clusterctrl status</code>. My controller also has the ClusterHAT still on top, so the output includes the details of that devices: pi@cbridge$ clusterctrl status clusterhat:1 clusterctrl:1 maxpi:7 ctrl_bus:20:3:3 hat_version:2.3 hat_version_major:2 hat_version_minor:3 hat_size:4 hat_uuid:7a840d46-de0a-44e0-9057-f949d0d5e848 hat_vendor:8086 Consultancy hat_product_id:0x0004 throttled:0x0 hat_alert:0 hat_hub:1 hat_wp:1 hat_led:1 hat_wplink:0 hat_xra1200p:True p1:0 p2:0 p3:0 p4:0 ctrl20:FW:1.2 ADC1:4866mV T1:12.86C p5:0 u5:1 p6:0 u6:1 p7:0 u7:1 </code></pre> The key pieces are near the top: clusterctrl:1 maxpi:7 ctrl_bus:20:3:3 </code></pre> And near the end: ctrl20:FW:1.2 ADC1:4866mV T1:12.86C p5:0 u5:1 p6:0 u6:1 p7:0 u7:1 </code></pre> Because of the ClusterHAT, you can see the numbering for the Cluster Triple devices starting at p5</code>. Initially all three CMs are powered off to start (p5:0</code>), and configured with USBBOOT enabled (u5:0</code>) Installing Raspbian To CMs</h2> Because I'm running off the eMMC, I followed the guide for How to write an image to the eMMC</a>. Once done downloading the P1 image and writing it to the eMMC, I can happily SSH into the nodes: Next Steps</h2> Next, I will be working on getting the controller node running as a Kubernetes control node, and the three CM nodes setup as Kubernetes nodes! Pimera Project: FreeBSD 2019-08-27T00:00:00+00:00 Based on my suspension of the KubeHat project</a> and initial efforts on my new Pimera project</a>, my first step is a stab at getting FreeBSD running on one of the Pi Zeros! Goals</h2> The following are my goals for getting FreeBSD working on one of the Raspberry Pi Zeros in my Cluster HAT setup: Don't impact operation of the rest of the cluster.</li> Latest current FreeBSD (13-CURRENT is the only version that fully worked for me)</li> Feature parity with Raspbian, including bridged networking, SSH server, mDNS discovery.</li> All configured to come up automatically on boot</li> </ol> I'm going to be using the FreeBSD Pi wiki page</a> as a starting point, and going from there. Disk Image</h2> First, I brought down the existing p4</code> Pi Zero from the controller, leaving the rest of the cluster running: pi@controller$ clusterhat off p4 </code></pre> Once that completed, the status light for the fourth cluster device went dark, and I could remove the SD card and plug it into my laptop. Next, I downloaded the latest snapshot disk image from https://download.freebsd.org/ftp/snapshots/arm/armv6/ISO-IMAGES/</a> Once downloaded, from my Linux laptop, I unzipped the image: peter@localhost$ unxz FreeBSD-13.0-CURRENT-arm-armv6-RPI-B-20190822-r351363.img.xz </code></pre> Next, I wrote the image to my SD card: peter@localhost$ sudo dd if=FreeBSD-13.0-CURRENT-arm-armv6-RPI-B-20190822-r351363.img of=/dev/mmcblk0 bs=4M conv=fsync </code></pre> When that completed, I removed the SD card from my laptop, re-inserted it into the fourth Pi Zero slot Running FreeBSD</h2> Next, I brought the fourth Pi Zero device back online in the cluster from the controller: pi@controller$ clusterhat on p4 </code></pre> From there, running dmesg</code> I can see eventually the FreeBSD device come live, and register the virtual serial console: pi@controller$ dmesg | tail -n 8 [861430.624826] usb 1-1.2.1: new high-speed USB device number 10 using dwc_otg [861435.764830] usb 1-1.2.1: device descriptor read/64, error -110 [861436.017185] usb 1-1.2.1: New USB device found, idVendor=16c0, idProduct=27dd, bcdDevice= 1.00 [861436.017211] usb 1-1.2.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 [861436.017223] usb 1-1.2.1: Product: Virtual serial port [861436.017235] usb 1-1.2.1: Manufacturer: The FreeBSD Project (https://www.FreeBSD.org) [861436.017247] usb 1-1.2.1: SerialNumber: FreeBSD1 [861436.089370] cdc_acm 1-1.2.1:1.0: ttyACM3: USB ACM device </code></pre> Logging into FreeBSD</h2> Using the tio</code> utility (or screen</code>, if you prefer), you can log into FreeBSD on the Pi Zero over the virtual serial console: pi@controller$ tio /dev/ttyACM0 [tio 18:58:58] tio v1.32 [tio 18:58:58] Press ctrl-t q to quit [tio 18:58:58] Connected FreeBSD/arm (p4) (ttyU0) login: </code></pre> If using tio</code>, you may need to hit Enter</kbd> once to get the login prompt to appear. You can then log in using the default root:root</code> combo from the base image. USB Device Mode Network Device</h2> In order to access the FreeBSD Pi over SSH, we'll need to get FreeBSD to create a virtual ethernet device via USB device mode that the main controller Pi will bridge to the physical ethernet adapter on that device. Taking inspiration from the instructions from the FreeBSD Handbook</a>, well edit /boot/loader.conf</code>, using vi</code> to do so (which is part of base) to do the following: Change the USB template mode to 8</code> so we get both serial console and networking. See usb_template(4)</a>.</li> Make sure the if_cdce</code> driver is loaded at boot, so the network device can load.</li> </ol> You should end up with the following lines in that file: if_cdce_load="YES" hw.usb.template=8 </code></pre> Then reboot FreeBSD: root# reboot </code></pre> Once the device reboots, you should see a new line in the dmesg</code> output: pi@controller$ dmesg | tail -n 1 [864885.946765] cdc_ether 1-1.2.1:1.2 usb0: register 'cdc_ether' at usb-3f980000.usb-1.2.1, CDC Ethernet Device, 2a:02:03:04:05:06 </code></pre> Unfortunatly, the MAC address that FreeBSD will use for the USB ethernet device will not match the ones originally configured in the Cluster HAT Raspbian images, and so the newly created device on the controller side will be usb0</code>, and not properly bridged automatically: pi@controller$ ifconfig usb0 usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 2a:02:03:04:05:06 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 </code></pre> To fix this, we'll note the MAC address, e.g. 2a:02:03:04:05:06</code> and update the file /etc/udev/rules.d/90-clusterhat.rules</code> with that MAC address, Since I'm using p4</code> for my FreeBSD instance, I'll update the line like so: SUBSYSTEM=="net", ATTR{address}=="2a:02:03:04:05:06", NAME="ethpi4" </code></pre> Now, rebooting the FreeBSD instance from the serial console should show the following dmesg</code> output from the controller: [81069.650887] usb 1-1.2.1: new high-speed USB device number 22 using dwc_otg [81074.780880] usb 1-1.2.1: device descriptor read/64, error -110 [81075.033585] usb 1-1.2.1: New USB device found, idVendor=16c0, idProduct=05dc, bcdDevice= 1.00 [81075.033603] usb 1-1.2.1: New USB device strings: Mfr=6, Product=7, SerialNumber=8 [81075.033615] usb 1-1.2.1: Product: Serial/Ethernet device [81075.033628] usb 1-1.2.1: Manufacturer: The FreeBSD Project (https://www.FreeBSD.org) [81075.033639] usb 1-1.2.1: SerialNumber: FreeBSD1 [81075.116046] cdc_acm 1-1.2.1:1.0: ttyACM0: USB ACM device [81075.121932] cdc_ether 1-1.2.1:1.2 usb0: register 'cdc_ether' at usb-3f980000.usb-1.2.1, CDC Ethernet Device, 2a:02:03:04:05:06 [81075.200713] cdc_ether 1-1.2.1:1.2 ethpi4: renamed from usb0 [81075.555493] br0: port 3(ethpi4) entered blocking state [81075.555506] br0: port 3(ethpi4) entered disabled state [81075.556209] device ethpi4 entered promiscuous mode [81075.620942] br0: port 3(ethpi4) entered blocking state [81075.620957] br0: port 3(ethpi4) entered forwarding state </code></pre> Now that the controller side is configured, we'll set up DHCP inside of FreeBSD, via the serial console. Edit /etc/rc.conf</code> to add the following line: ifconfig_ue0="SYNCDHCP" </code></pre> Where ue0</code> is the name of the USB mode ethernet device that FreeBSD creates. Once that is done, run the following from FreeBSD: root# service netif restart dhclient not running? (check /var/run/dhclient/dhclient.ue0.pid). Stopping Network: lo0 ue0. lo0: flags=8048<LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> ue0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 2a:02:03:04:05:f9 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Starting dhclient. DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 192.168.1.1 bound to 192.168.1.212 -- renewal in 43200 seconds. Starting Network: lo0 ue0. lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 2a:02:03:04:05:f9 inet 192.168.1.212 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> </code></pre> After that, you should have working network access from the FreeBSD Pi: root# ping google.com PING google.com (172.217.10.238): 56 data bytes 64 bytes from lga25s59-in-f14.1e100.net (172.217.10.238): icmp_seq=0 ttl=56 time=36.768 ms 64 bytes from lga25s59-in-f14.1e100.net (172.217.10.238): icmp_seq=1 ttl=56 time=35.297 ms </code></pre> Passwords, Hostname, NTP</h2> Next, you should update the passwords for root</code> and freebsd</code> users: root# passwd Changing local password for root New Password: Retype New Password: root# passwd freebsd Changing local password for freebsd New Password: Retype New Password: </code></pre> You should update the hostname in /etc/rc.conf</code> to match the numbered Pi Zero, e.g. p4</code>: hostname="p4" </code></pre> Because there is not persistent real time clock on the Pi Zero, you'll want to enable ntpd</code> in /etc/rc.conf</code> as well so you have accurate time on the device: ntpd_enable="YES" ntpd_sync_on_start="YES" </code></pre> Once enabled, reboot your FreeBSD Pi once more for all the changes to take effect. Using pkg for package management</h2> See the Packages and Ports</a> handbook section for setting up pkg</code> and adding packages like neovim</code>, tmux</code>, etc. Multicast DNS (i.e. ZeroConf) Configuration</h2> I haven't yet been able to get mDNS working for the FreeBSD instance. In particular, the mDNSResponderPosix</code> keeps segfaulting after starting. Perhaps at a later date I will recompile with debug symbols and dig into the details. End Result</h2> Pimera Progress</h2> So far, we've got the following completed for the Primera Project Next Step: Alpine Linux</h2> NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on p2</code> next! KubeHat Project Suspended 2019-08-26T00:00:00+00:00 Going into this project, I knew there was going to be an unhill battle, since the Pi Zeros on the hat run ARMv6. Debian/Ubuntu only target ARMv7 with their armhf</code> packages, so many packages built for ARM from other ISVs, e.g. kubernetes, docker, etc are built targetting ARMv7 as well. After the initial Raspbian setup, I had some early successes, getting things like buildah</a>, podman</a>, and cri-o</a> as working. Unfortunatly, further digging on Kubernetes itself has revealed that all semi-recent versions require the cpuset</code> cgroups functionality. Attempting to compile the kernel with that feature reveals that it can only be enabled if SMP is enable, which isn't an option on the ARMv6 platform at all. Argh! Given that reality, I'm going to (temporarily?) suspend my efforts on KubeHat. If such a time as the Raspberry Pi Foundation releases a model in the Pi Zero format with an updated SoC based on the ARMv7 architecture, I'm excited to take another stab at this. In the meantime, I will be doing two things. Trying to get (Pi-hole)[https://pi-hole.net/] running via Podman on the main ARMv7 controller board.</li> A new project that came to me while not sleeping...</li> </ol> Coming Soon: Raspberry Pi + Chimera = Pimera</h2> Pimera Project Intro 2019-08-26T00:00:00+00:00 Raspberry Pi + Chimera = Pimera</h2> Since the original KubeHat</a> is on hold, I was inspired to instead try to create the most diverse single Raspberry Pi cluster I could imagine. Inspired by the mythical Chimera</a>, I've decided to call this effort, "Pimera". Planned Operating Systems</h2> This list may get revised, but my current rough plan is: Controller</h3> I plan to stick with Raspbian Buster for the main controller. I will probably do a fresh install of this, plus my various podman, etc. dependencies, to get rid of some of the Kubernetes cruft that accumulated from my efforts there. The main advantage here is getting the basic clusterhat</code> CLI and the briding network setup from the base Cluster HAT provided images, and avoid having to set that up myself. Pi Zeros</h3> The following is my current OS target list for the Pi Zeros on the Cluster HAT: FreeBSD</a></li> NetBSD</a></li> Alpine Linux</a></li> TBD</li> </ol> Next Up: FreeBSD for the Pi Zero</h2> Next up, I'll document setting up FreeBSD on the Pi Zero. KubeHat Project Software Setup 2019-08-06T00:00:00+00:00 The clusterhat website provides custom Rasbian images</a> for both the controller and Zero devices, that includes: clusterhat</code> utility to control power/hub to the Zeros via i2c.</li> Networking setup for brudge/NAT so all devices can connect to the network via the ethernet port on the controller.</li> Hostnames for controller</code>, p1</code>, p2</code>, etc as well as avahi setup so you can easily SSH to p1.local</code> etc from your local machine.</li> </ul> The custom images do not enable sshd</code> automatically, and since I'm only ever going to have this cluster networked, and to avoid having to fiddle with HDMI cables, before copying the images to the SD cards, I mounted each image and added the /boot/ssh</code> file as normal. You could get away with only enabling sshd</code> on the controller, and accessing the Pi Zeros via the serial console if you'd rather do that. Once you have the images copied to the SD cards and they are inserted to all the Pis, you can power on the controller. From there, assuming you've set up mDNS resolution on your local machine (macOS has this OOTB, many Linux distros as well), you can SSH into your controller using the password clusterhat</code>: $ ssh pi@controller.local </code></pre> Once in the controller, you'll likely want to do to raspi-config --expand-rootfs</code> to expand the partitions to use the whole SD card before continuing. Once that is done and you've restared the controller Pi, you can ssh back in and use the following command to power on the Pi Zeros: pi@controller$ clusterhat on </code></pre> After that, you should see the status lights for the Zeros illuminate, and running dmesg</code> should show various USB gadget devices showing up, along with their network adapters, and tty devices for serial console connections. Pi Zero Access</h2> If you didn't enable SSH on the Zeros. then you can access the serial console on the TTY devices from the controller</code>, e.g. ttyACM0</code>, using screen: pi@controller$ apt-get install screen pi@controller$ screen /dev/ttyACM0 p1 login: </code></pre> Alternately, you can just ssh into the Zeros using the mDNS name, e.g. p1.local</code>: $ ssh pi@p1.local pi@p1.local's password: </code></pre> T-Mux Synchronization</h2> A note about performing the same steps on all the Pi Zero devices in the cluster. Leveraging tmux</code>'s ability to synchronize a set of panes makes performing bulk operations on all devices a breeze. In a nutshell, I use the following process whenever I need to do the same actions on all four Zeros: SSH into the controller</code></li> Run tmux</code> (install this first w/ apt-get install tmux</code>).</li> Use C-b "</code> and C-b %</code> to open four panes, C-b</code> and the arrows to navigate as needed.</li> Use C-b</code> + arrow keys to switch to each pane, and SSH into each Zero, or start up screen sessions on each TTY device.</li> Once all four devices are at the same state, with an active logged in session, use C-b :set synchronize-panes<Enter></code>.</li> Now, anything typed into tmux, pasted, etc will be sent to all four Pi Zero sessions, such as running dist upgrades, installing packages, editing files, etc.</li> Once you're done, you can do C-b :set synchronize-panes off<Enter></code> to stop synchronizing.</li> </ol> Note: Most of the time I do this by first SSH-ing into the controller device first. I do this, so that if for whatever reason my local workstation disconnects, sleeps, etc. then the tmux session on the controller will persist, including the child sessions on each Zero, and I can SSH back into controller</code> and then tmux attach</code> to get back to what I was working on. </aside> Expand Partitions</h2> Similar to the controller, you'll want to expand the root filesystem for the Zeros. Setup the synchronized tmux sessions as described above, then run raspi-config --expand-rootfs</code>. Once completed, reboot the Zeros to complete the process. Password Update For pi User</h2> For the controller, and for any of the Zeros that have SSH enabled, you'll want to change the default pi</code> user password. Using tmux to multiplex the following steps to all the devices, including the controller, if you want: Next Steps</h2> Next post, I'll dive into my efforts to get the dependencies for running Kubernetes installed for the controller Pi, and the armv6</code>-based Pi Zeros, which present a challenge since many packages build for Debian/Ubuntu are armv7</code>-compatible only. KubeHat Project Intro 2019-08-05T00:00:00+00:00 A while back, I read this post</a> by Scott Hanselman about his project to set up a Raspberry Pi cluster. More recently, I stumbled upon the very cool Cluster HAT</a> add-on for the Raspberry Pi. In a nutshell, its a simple HAT that allows adding four Pi Zeros all connected to the main controller Pi via USB Gadget mode. The Zeros can either piggyback on the controllers network connection in bridged or NAT mode, or use wireless to connect independently to the network if using Zero W's. At the time, there was no availability to buy Cluster HATs that could ship to the US reasonably, so I shelved the idea. Recently, the minor revision Cluster HAT v2.3 was released, and with it I was able to find a full kit, with four Pi Zero W's, the HAT, and the necessary microSD cards for a good price on PiShop.us</a>. To boot, they had a nice case</a> available for only $16 more. I decided to go for it, and ordered the kit and the case, since I already had a Pi 3B+ at home that wasn't getting much use. Once i received the shipment, the assembly was fairly straightforward using this guide</a>. The case included all the necessary risers to add the HAT and nicely place the combination of the controllers and Zero's. Included are some clear light tubes to bring the indicator lights for the HAT to the surface of the case. after removing the surface tape as needed, i had to do some gentle sanding on a few rough corners to make them slide into place. The final product was a nice little cluster of Pis. Final Build</h2> Next post, I'll outline the steps I used to getting basic software and control running, and following that I'll explore my attempts at getting Kubernetes up and running.

Installing Helm</h3>
If you don't already have Helm installed, check out the installtion options</a> to get the `helm</code> CLI installed. I used Helm V3, although this should work fine with Helm V2 as well.</p>`

`Next Steps</h2> Next, I'll work in setting up things like Kubernetes Dashboard, Prometheus, etc!</p>`

Hardware Setup</h2>
I assembled the CMs into the Cluster Triple board, attached the provided USB cable to the controller USB port and the `USB</code> port on the board, then plugged a micro USB charger into the PWR</code> port on board.</p>`
`</p>`

Next Steps</h2>
Next, I will be working on getting the controller node running as a Kubernetes control node, and the three CM nodes setup as Kubernetes nodes!</p>

Using pkg for package management</h2>
See the Packages and Ports</a> handbook section for setting up `pkg</code> and adding packages like neovim</code>, tmux</code>, etc.</p>`

`End Result</h2> </p> Pimera Progress</h2> So far, we've got the following completed for the Primera Project</p> </p> Next Step: Alpine Linux</h2> NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on p2</code> next!</p>`

Pimera Progress</h2>
So far, we've got the following completed for the Primera Project</p>
</p>

Next Step: Alpine Linux</h2>
NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on `p2</code> next!</p>`

Coming Soon: Raspberry Pi + Chimera = Pimera</h2>

Raspberry Pi + Chimera = Pimera</h2>
Since the original KubeHat</a> is on hold, I was inspired to instead try to create the most diverse single Raspberry Pi cluster I could imagine. Inspired by the mythical Chimera</a>, I've decided to call this effort, "Pimera".</p>

`Pi Zeros</h3> The following is my current OS target list for the Pi Zeros on the Cluster HAT:</p>FreeBSD</a></li> NetBSD</a></li> Alpine Linux</a></li> TBD</li> </ol> Next Up: FreeBSD for the Pi Zero</h2> Next up, I'll document setting up FreeBSD on the Pi Zero.</p>`

Next Up: FreeBSD for the Pi Zero</h2>
Next up, I'll document setting up FreeBSD on the Pi Zero.</p>

`Next Steps</h2> Next post, I'll dive into my efforts to get the dependencies for running Kubernetes installed for the controller Pi, and the armv6</code>-based Pi Zeros, which present a challenge since many packages build for Debian/Ubuntu are armv7</code>-compatible only.</p>`

Final Build</h2>
</p>
Next post, I'll outline the steps I used to getting basic software and control running, and following that I'll explore my attempts at getting Kubernetes up and running.</p>

My Blog

A New Journey

Home?</h1>
We've sold our home! Our new</em> home is going to be a "rig", composed of a pick-up truck and an RV trailer, which we will be living in full time for the foreseeable future! We're ironing out the details, and I'll post more pics when I can.</p>

Cluster Triple - GitLab Runner

Cluster Triple - k3s setup

Cluster Triple - A new Kubernetes cluster attempt

Pimera Project: FreeBSD

KubeHat Project Suspended

Pimera Project Intro

KubeHat Project Software Setup

KubeHat Project Intro

My Blog

A New Journey

Home?</h1> We've sold our home! Our new</em> home is going to be a "rig", composed of a pick-up truck and an RV trailer, which we will be living in full time for the foreseeable future! We're ironing out the details, and I'll post more pics when I can.</p>

Non-OSS Work Funds OSS Work</h3> Some example models that fit this:</p> Sell commercial support/consulting/services based on the OSS project.</li> Commercial product built on open source core.</li>

Directly Funding OSS Work</h3> This includes approaches like:</p>

Getting Paid To Do What I Love?</h2> As I imagined how I might want to approach this, a set of priorities stuck out:</p>

Cluster Triple - GitLab Runner

Goals</h2> Install GitLab Runner on the new Kubernetes Cluster running on the Cluster Triple + Base Pi.</li>

Helm Chart Values</h3> To install the GitLab helm chart, there are some required configuration values that need to be passed. The full values.yaml</code> file that worked for me was the following:</p>

Install The Chart</h3> We'll install the gitlab-runner</code> helm chart into a separate namespace, named gitlab-runner</code>, so we'll install the helm chart with the following:</p>

Cluster Triple - k3s setup

Goals</h2> Run CBRIDGE</code> controller Pi as the Kubernetes master node</li> Join the three CM devices in the Cluster Triple as nodes in the cluster</li> Verify working behaviour of Kubernetes, with run of a simple command in a pod in the cluster</li>

Next Steps</h2> Next, I'll work in setting up things like Kubernetes Dashboard, Prometheus, etc!</p>

Cluster Triple - A new Kubernetes cluster attempt

Board Specs</h3> Onboard 4-port USB 2.0 hub</li> ClusterCTRL (I2C) USB interface allows individual control of Pi power, fan, LED, etc.</li> Programmable power on states for LED, Individual Pi Power, USBBOOT, etc.</li>

Hardware Setup</h2> I assembled the CMs into the Cluster Triple board, attached the provided USB cable to the controller USB port and the USB</code> port on the board, then plugged a micro USB charger into the PWR</code> port on board.</p> </p>

Initial status</h2> Once you log into the bridge controller, you can see the status of the Cluster Triple by running clusterctrl status</code>. My controller also</em> has the ClusterHAT still on top, so the output includes the details of that devices:</p>

Pimera Project: FreeBSD

Running FreeBSD</h2> Next, I brought the fourth Pi Zero device back online in the cluster from the controller:</p>

Logging into FreeBSD</h2> Using the tio</code> utility (or screen</code>, if you prefer), you can log into FreeBSD on the Pi Zero over the virtual serial console:</p>

Using pkg for package management</h2> See the Packages and Ports</a> handbook section for setting up pkg</code> and adding packages like neovim</code>, tmux</code>, etc.</p>

End Result</h2> </p> Pimera Progress</h2> So far, we've got the following completed for the Primera Project</p> </p> Next Step: Alpine Linux</h2> NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on p2</code> next!</p>

Pimera Progress</h2> So far, we've got the following completed for the Primera Project</p> </p>

Next Step: Alpine Linux</h2> NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on p2</code> next!</p>

KubeHat Project Suspended

Coming Soon: Raspberry Pi + Chimera = Pimera</h2>

Pimera Project Intro

Next Up: FreeBSD for the Pi Zero</h2> Next up, I'll document setting up FreeBSD on the Pi Zero.</p>

KubeHat Project Software Setup

KubeHat Project Intro

Home?</h1>
We've sold our home! Our new</em> home is going to be a "rig", composed of a pick-up truck and an RV trailer, which we will be living in full time for the foreseeable future! We're ironing out the details, and I'll post more pics when I can.</p>

`Next Steps</h2> Next, I'll work in setting up things like Kubernetes Dashboard, Prometheus, etc!</p>`

Hardware Setup</h2>
I assembled the CMs into the Cluster Triple board, attached the provided USB cable to the controller USB port and the `USB</code> port on the board, then plugged a micro USB charger into the PWR</code> port on board.</p>`
`</p>`

Using pkg for package management</h2>
See the Packages and Ports</a> handbook section for setting up `pkg</code> and adding packages like neovim</code>, tmux</code>, etc.</p>`

`End Result</h2> </p> Pimera Progress</h2> So far, we've got the following completed for the Primera Project</p> </p> Next Step: Alpine Linux</h2> NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on p2</code> next!</p>`

Pimera Progress</h2>
So far, we've got the following completed for the Primera Project</p>
</p>

Next Step: Alpine Linux</h2>
NetBSD I'm not sure in fact supports the "USB Gadget" functionality, so I'm going to try to get Alpine Linux going on `p2</code> next!</p>`

Next Up: FreeBSD for the Pi Zero</h2>
Next up, I'll document setting up FreeBSD on the Pi Zero.</p>