The VMworld Hackathon I failed to attend… And how our team won – Part 3
While we had a great story and a good plan on how to make sure we achieved our goals during the hackathon, our team also met a problem where I was unable to attend the hackathon at the last minute because of a work situation.
This left our team with one fewer backend developer, making it harder for the rest.
So we shifted our plan slightly. The hackathon itself was during the evening of the first day of VMworld Europe. This left me with a day to develop a portion of the backend that would at least fulfill the requirement of Phase 1.
Phase 1 was where there was a tool that would manage the life and death of pods in Kubernetes according to Conway’s Game of Life rules.
Developing and documenting this during the day, meeting in the late afternoon with the team to give them a crash course in what I had done, allowed us to stay relatively on track, and would give the team a base to continue on during the hackathon itself.
This is a story in 3 parts:
- Part 1 – The team and the goal
- Part 2 – The story, the plan and the problem
- Part 3 – The implementation, the result and the future
The implementation
Overall, the code can be found in the teams GitHub repository, I’ll be focussing mainly on the backend as that is what i worked on and i don’t have a lot of information on the other components, because i wasn’t at the hackathon…
The backend – Kube of Life
As I had some experience in working with Kubernetes and with python, i decided to use python to build a tool that could interact with Kubernetes and contain the following functionalities for Phase 1:
- Build a grid of alive and death cells, based on an input pattern
- Deploy the alive cells as pods in Kubernetes
- Implement the Conway’s Game of Life rules to destroy and create K8s pods
- Implements a basic webserver to display the grid and to provide an API
All of the code can be found on the Kube-of-Life GitHub repository.
I used kubernetes python modules to communicate with the Kubernetes API. For the webserver to display a basic version of the grid and to provide some API output, I used Flask.
From a logic perspective the code provides a basic shell command after installation which will start both the backend and the frontend, which will each run in their own thread, sharing information. This way, the backend can run at its own pace, managing the Kubernetes environment, while the frontend can handle calls being made and can read data that the backend makes available.
Once the backend is started, the first thing it will do is either generate a random grid of the size defined in the configuration file, or it will import an existing grid if so defined. That way, you can predetermine the start grid of alive pods.
The next step is to create the necessary pods in K8s as per the alive cells in the grids. The backend will create a pod for each cell on the grid that is alive. The backend can then wait for all pods to come up.
The backend will then go into a loop and for each iteration, it will calculate what the new grid configuration should be, taking the Conway’s Game of Life rules into account:
- Alive cells with 2 or 3 alive neighbours, stay alive
- Death cells with 3 alive neighbours, become alive
- Alive cells with less than 2 neighbours, die out of starvation
- Alive cells with more than 3 neighbours, die out of over-population.
Once the backend has calculated the new grid configuration of alive an death cells, it will create and destroy pods as necessary in Kubernetes.
Each time the backend updates the grid and creates and destroys pods (including the initial setup of the grid), it will generate an output for the frontend thread. Using this data, the frontend will display a grid of grey and green pixels, identifying which pod is alive and which is dead space.
The frontend also provides a JSON output of the grid, so that other tools can use this data.
The actual frontend
Lino took on the responsibility to build a frontend using VMware Clarity. The goal of this was to display the grid in its current state, and dynamically update that grid so you could see the pods evolving through life and death.
It would run as a container itself, connecting to the backend API that provided it with the data it needed.
The code for this can be found on GitHub.
The result
While I was not present at the hackathon myself, the team did a wonderful job in continuing the work, working together in figuring out in how to use my code and to come up with some great examples of how to use this.
We eventually settled on running the code and showing the outcome based on an initial grid spelling the word “VMworld” and to see how it would evolve, potentially into a stable state.
The above image is the evolution of life with the standard rules, beginning from a starting grid spelling the word “VMworld”. Each green cell is an actual pod running on Kubernetes.
You can see that over time, it eventually stabilizes in two well known patterns for the Game of Life rules.
Winning the VMworld Europe Hackathon
With all the work that went into this Hackathon, and the problems faced, the team actually won!
The team gave a great presentation, and apparently the jury decided that this project was the most fun and cool one of the year, awarding the team with the first place. And as the team was nice enough to include me in the member list, I also received the price, a nice VMware bomber jacket.
There’s also a lot of tweets about our experience, and a blog post by Acens on our win, which has an interview with me as well (skip that part, really…)
The future
While this was an incredible experience for me to learn how to code and automate against the Kubernetes API, it is definitely not the end for me.
The goal is to learn more by implementing the next phases, so i understand better what Kubernetes does and how i can create better integrations and tools that provide extra capabilities for Kubernetes.
I want to look into deploying this as a pod, using a service account. I want to create an operator out of this that would do proper lifecycle management and implements an upgrade strategy.
We’ll see where this takes me, but it surely was a lot of fun, and i definitely want to thank my team members and the VMware {code} organization for all the fun and the learning experience.
