Live and let Learn

In mid 2022 I was presented with an amazing opportunity through no effort of my own: VMware, the company I worked for, announced it was being acquired by a non-remote, non-open-source-oriented multi-national in a somewhat lengthy 18 month process. As a fully-remote staff engineer on an open-source project I estimated a 75 to 90 percent probability that I’d receive a redundancy in around 18 months time.

A redundancy, really? An amazing opportunity? This post is a personal reflection and reminder to my future self to step back and evaluate the potential opportunities that a situation provides. I’m currently using this opportunity to weave three passions of mine into a possible future of software engineering with Rust on quantum computing projects and piloting aeroplanes on the side. Sure, reality may force me to compromise in one way or another in time, but for now I’m leaving my options open.

[Read More]

The Day 03 challenge involves the calculating whether a character symbol is adjacent to a part number in a two dimensional map, such as: 467..114.. ...*...... ..35..633. ......#... 617*...... .....+.58. ..592..... ......755. ...$.*.... .664.598.. and then doing things with the part numbers. To calculate whether a symbol is adjacent to a part number we’re going to need: the position of each symbol, the position of each number, the length of the token for each number. [Read More]

After refreshing my knowledge of the rust parsing library ’nom’ with the day01 challenge, I was keen to do the second challenge without, simply using the standard library’s string manipulation and default parsing for this simpler parsing problem. At the same time, I was keen to work more with GitHub Copilot since I’ve not been able to use copilot at my most recent job due to potential legal issues. The Elf’s game for day 02 consists of pulling out multiple combinations of red, green and blue balls from a sack - and the parsing looks quite straight forward. [Read More]

It’s been quite some time since I’ve taken time to enjoy coding challenges primarily for the fun of it. Over the next months, I’m keen to work my way through the 2023 Advent of Code - a fun set of problems created by Eric Wastl strung together with a seasonal story - and write up a bit about my own learning and fun. For me it’s a chance to keep improving my fluency with various Rust libraries and tools (start learning the Rust programming language here! [Read More]

One of the great aspects of working at a larger company like VMware is that there are programs like Take 3, designed to help people who meet certain criteria to take 3 months on a different project to learn new skills in other contexts and bring those skills and experience back to their team - rather than potentially looking elsewhere for a similar learning experience. This post documents my own recent learning experience of an exciting Take3 project at VMware, with the hope that others may be able to take up the opportunity to learn and bring new skills back to their teams. [Read More]

During a career as a software engineer, every now and then you come across a design pattern that becomes your darling for a few years following the discovery. Other design patterns are useful, but not so special that you want to tell the world about them.

Up until recently, my favourite design pattern was the state pattern which allows encapsulating different behaviours (implementations of an interface) in different classes so that an object can delegate its functionality to different state implementations which can be update at runtime. But more recently, while using a lot of concurrency in certain Kubeapps services, I’ve fallen in love with another design pattern - the fan-out/fan-in messaging pattern (or a form of it).

[Read More]

The recent release of Kubeapps marks a milestone for the Kubeapps team in that we are no longer restricted to presenting a catalog of only Helm packages in our UI and, behind the scenes, we’ve addressed a long-standing security issue to remove the reverse proxy to the Kubernetes API server that our UI depended on until now. We’ve done a few overviews of the new Kubeapps APIs service which makes this possible (see Kubeapps APIs: Beyond Helm, or the TanzuTV episode 74 where Antonio gives an in-depth demo of the Carvel support), or more recently, a demo of the Flux and Carvel support together: But in this post I’d like to write something a little more detailed about the choices we made as well as some of the implementation details. [Read More]

This is the second post in a series of two post detailing the steps that I took to install Kubeapps running on a TKG 1.3 cluster on AWS configured to allow user authentication via the TKG identity management: The first post focuses on the TKG 1.3 setup required to get a workload clusters with identity management (using your chosen identity provider), This followup post details the related Kubeapps installation and configuration on the TKG 1. [Read More]

Way back in 2020 I’d detailed how I’d setup a Tanzu Kubernetes Grid 1.1 management cluster with OpenID Connect support (for single sign-on) before installing Kubeapps with single sign-on on that management cluster. Recently TKG 1.3 was released and the identity management support in TKG has changed significantly, so it’s time to see what’s different when setting up a TKG cluster with identity management as well as how we can run Kubeapps on TKG 1. [Read More]

We’ve been able to run Kubeapps in a multi-cluster setup on various Kubernetes clusters for a while now, but this was dependent on the Kubeapps’ user being authenticated in a way that all the clusters trust. Up until now, this meant having all the clusters configured to trust the same OIDC identity provider, which is not possible in some Kubernetes environments.

Particularly, this meant we were unable to demonstrate multi-cluster Kubeapps with clusters created by Tanzu Mission Control since we can’t specify API server options, such as OIDC configuration, when creating a cluster in TMC. But that requirement has now changed thanks to a new project called Pinniped.

[Read More]