What are these critters?

In YAML’s cryptic language, an anchor (&) is like a bookmark, and a reference (*) is you going back to said bookmark because you forgot where you were.

For the visual learners (and the rest of us pretending to be):

The Old Way:

metadata:
  name: really-cool-app

And repeat that name everywhere.

The New (to me) Way:

metadata:
  name: &appName really-cool-app
...
spec:
  releaseName: *appName

Ta-da! That &appName is our sneaky bookmark, and *appName is us coming back for a refresher.

Why does this even matter?

1. Efficiency: It’s like copy-pasting, but fancier.
2. Consistency: Reduce the chances of a rogue typo messing up your YAML (not that I’ve ever done that, obviously).

But heed this: your anchor has to pop up before its reference, and after tweaking, give it a once-over (or thrice-over, depending on your coffee intake).

In wrapping up this riveting tale of YAML wizardry, remember: no matter how tall the tech stack, there’s always a corner we haven’t peeked around. Here’s to lurking symbols, silent chuckles, and the never-ending tech scavenger hunt.

For a deeper dive into YAML anchors and aliases, refer to the official YAML 1.2.2 specification.

Further reading

For a deeper dive into YAML anchors and aliases, refer to the official YAML 1.2.2 specification.

I plan to maximize the use of my consumer-grade SSDs before transitioning completely to enterprise-grade. My strategy is to establish a new pool with durable NVMe drives mirrored to my consumer ones. Given that my least healthy drive still retains over half of its write lifespan, and considering the impressive 2.5PB durability of the PM983s compared to the premature failing 800TB consumer SSDs, it’s anticipated that I will deplete my consumer-grade stock first.

Steps:

1. Backup: Ensure you have a full backup before beginning.
2. Downtime: Migrate data to the backup machine using zfs send and zfs receive. If this isn’t feasible, establish a maintenance window.
3. Initialize New ZFS Pool: Form a fresh ZFS pool with the enterprise SSDs, and for clarity, I’m designating them as consumer-pool and durable-pool.
4. Data Migration: Shift datasets from consumer-pool to durable-pool.
5. Detach Consumer SSDs: Safely disengage consumer SSDs from consumer-pool.
6. Partition Resizing: Modify consumer SSD partitions to coincide with enterprise SSD sizes and then reformat.
7. Mirror Integration: Merge the resized consumer SSDs with the durable-pool.
8. Data Verification: Cross-check data consistency across both pools using ZFS’s checksum capabilities.
9. Old Pool Decommission: Upon successful validation of durable-pool, decommission consumer-pool.
10. Implement Hot-Spares: Assign the surplus consumer SSDs as hot spares within durable-pool.
11. Activate New Zpool: Transition operations based on your storage strategy.

Resizing

Given the use of fdisk, we’ll work with sectors. To illustrate, for a disk showing as 1.7TB and 1920383410176 bytes, sectors are computed as:

Sectors (1.7TB) = 1920383410176 bytes / (512 bytes/sector)

Adjust the calculations as necessary for different block sizes.

For a streamlined operation, after confirming the sequence above, it can be echoed as shown to facilitate batch processing or loop operations:

echo -e "g\nn\n\n\n3750748848\nw\n" | fdisk /dev/nvme6n1

Conclusion:

This strategy eased my transition to enterprise SSDs without forsaking my consumer SSDs. Though certain steps entail risks, vigilance and adequate preparation ensure smooth migration. Remember: Preparation is key to any successful migration. Happy data transitioning!

Being based in the Bay Area and managing a complex home infrastructure – including Kubernetes clusters, VMs, and Proxmox nodes – I’ve faced the significant challenge of rolling blackouts. Here’s my journey, including the lessons learned, the solutions implemented, and my plans for the future.

The 2 AM Wake-Up Call

My UPS alarm went off at 2 AM, and with only 15 minutes of power left, I failed to turn off my nodes in time, leading to an unsafe shutdown. I knew I needed to develop a more strategic solution.

Manual Solution: The First Success

I wrote an Ansible playbook that drained the Kubernetes nodes and safely shut them down. During the next blackout, this manual method worked seamlessly, shutting down everything in a controlled manner. But I wanted something more robust.

Transition to Low-Power Mode: Essentials Stay On

Building upon my initial success, I optimized for a low-power mode that kept essential services running on a low-powered Celeron node, such as Home Assistant and Omada Controller. Additionally, a proxmox VM running OPNsense served as my backup firewall/router, providing critical connectivity. This allowed quick WiFi restoration and light control, creating a more resilient setup.

Custom Draining Explained

Here’s why I used specific options in the draining script:

kubectl drain $node --force --delete-local-data --ignore-daemonsets --selector='essential!=true'

The --force and --delete-local-data options ensure the node drains without getting stuck, even if local data must be deleted.

Low-Power Playbook Example

Here’s an excerpt from the playbook designed for low-power mode:

- hosts: workers
  tasks:
    - name: Custom Drain worker nodes
      command: /path/to/custom-drain.sh {{ inventory_hostname }}
    - name: Stop unnecessary worker nodes
      command: shutdown -h now

Future Plans: Full Automation

1. Monitor Power Status: Create a script that interfaces with the NUT server to keep an eye on power changes.
2. Trigger Playbooks: Automate the execution of playbooks during a power outage.
3. Reversing the Process: Develop a playbook to restore the system when power is back.

Conclusion

From an initial struggle to an elegant manual solution, and finally to a plan for full automation, I’ve turned the challenge of Bay Area’s blackouts into an opportunity to innovate my home infrastructure. For those facing similar challenges, this journey proves that with ingenuity and the right technical approach, you can build a resilient system that thrives in uncertainty.

Introducing: nomad-diner

Features:

• Location-based Searching: Drop an address or coordinates, and it spits out restaurants.
• Filters: Need at least a 4-star place? Or maybe you’re on a budget? The script’s got you covered.
• Search Term: Fancy sushi or perhaps a burger joint? Toss in a keyword.
• Driving ETA: If you think about driving, the script can give you a rough estimate of the time involved.

How It Operates:

• Coordinate Acquisition: The script accommodates both addresses and coordinates. Feed it an address, and it converts it into latitude and longitude.
• Efficient Filtering: By setting max_results and distance, you can further refine the results to more manageable numbers.
• Fetching the Essentials: Interacting with Google Places, the script curates a list of restaurants tailored to your criteria. For a comprehensive insight, it delves into detailed data for each establishment.
• Drive Time Calculation with Haversine Distance: Before the script decides to fetch the estimated driving time, it employs the Haversine Distance formula as a preliminary check. If a place is, say, only 100 meters away, there’s little sense in calculating driving time. The eta_threshold option in the script ensures unnecessary API calls are avoided.

Command-line Simplified:

The script runs from the command line. Here’s a sample command:

python script_name.py "Tokyo" --distance 5000 --min-rating 4.5 --max-price 2

This gets you restaurants within 5 kilometers of Tokyo, rated at least 4.5, with a price that won’t break the bank.

Final Thought:

Vacations should be about the experience, not not wrestling with meal choices. Hopefully this script helps someone else sidestep the food-finding fuss.

Why Hugo?

Hugo boasts simplicity, speed, security, and ease of use. It’s essentially a Go binary that transforms content written in markdown into static HTML websites. Its swiftness is unparalleled, and as for security – well, it’s only as secure as its hosting environment. Given that it only presents static HTML and assets, Hugo lacks backend vulnerabilities.

Step-by-step Guide:

1. Install Hugo

The official installation instructions can be found here.

For those in a hurry, here’s a tl;dr:

# Linux
sudo pacman -S hugo
sudo apt install hugo
# ...etc

# Mac (or Linux)
brew install hugo

# Windows
choco install hugo-extended

# Snap
sudo snap install hugo

# With Go
CGO_ENABLED=1 go install -tags extended github.com/gohugoio/hugo@latest

2. Create a Site

The official step-by-step commands can be found here.

# Creates a new site named "quickstart"
hugo new site quickstart
cd quickstart
git init

# Though I'm not usually a fan of git submodules, it simplifies theme
# installation and updating.
git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke.git themes/ananke

# Set 'ananke' as your theme. The hugo.toml file is central to site
# configuration. Your options may vary depending on your chosen theme.
echo "theme = 'ananke'" >> hugo.toml

# Preview your site live. Use Ctrl+C to stop.
hugo server

For a variety of themes, have a look at Hugo’s Official Themes Directory.

3. Add Content

hugo new posts/amazing-post.md
vim posts/amazing-post.md

Now, simply write your content in markdown:

---
title: "This post is simply amazing"
date: 2023-08-07T14:40:00-08:00
draft: true
---

Okay, so there's a little "metadata" header that contains info about your post.
That's what's shown above and it's pretty self-explanatory.

## Other than that, it's Just Markdown

Markdown is a lightweight markup language designed for plain text formatting.

![Sample Image](http://example.com/path/to/image.jpg)

## Main Content

### Subheading 1 You can **bold** text or _italicize_ it. 

- Bullet Point 1
- Bullet Point 2
 - Nested Bullet Point

### Subheading 2 Embed a link, like to this:
[awesome website](http://www.example.com), or incorporate quotes:

> Highlight text using blockquotes – perfect for famous quotations or
> emphasizing text.

## Code Snippets Markdown can elegantly display code:

\```python
def hello_world():
   print("Hello, world!")
\```

Note: I've added backslashes before the triple backticks to prevent them from
prematurely terminating the code snippet in this context. When implementing,
remember to remove those backslashes.

4. Deploy

There are a myriad of deployment options. For a comprehensive list, check Hugo’s official hosting and deployment recommendations.

On a personal note, I’ve hosted all my services with Kubernetes, making it a logical choice for this website too. I’ll soon share a post detailing that process.

Ever wondered how the vast universe of a video game or the near-instantaneous transmission of messages across continents gets distilled into the simplicity of ones and zeros? That’s the question that started my lifelong journey into the realm of technology.

During my school days, I was handed the profound paper “On Computable Numbers, with an Application to the Entscheidungsproblem.” Although it was a deep dive, it piqued my curiosity about the world of computing. An interesting twist from this period was when a discerning teacher handed me an installation CD for Slackware. And guess what? My initial experiment inadvertently led to a fresh start—by wiping our family computer clean! 😅

But every cloud has a silver lining. This gave me a platform to deep-dive into Slackware. By 12, I was navigating through its complexities. My tech endeavors didn’t stop there. I embarked on adventures with BSD, OpenBeOS, MS-DOS, and more. Each challenge, each stumble, and each line of code added a chapter to my story.

Fast forward a few years, and my audacious exploration led me into the very depths of a school Mac’s system. A little too deep, in fact, requiring a tech rescue mission by our school’s IT squad. It was a humbling reminder of the responsibility that comes with knowledge.

From there, my professional path took me to Emotional Brain Training and later, BioRAFT. Here, I’ve donned various hats, from a full-stack engineer to handling a Single Sign-On integration for millions globally. And now, 11 years later, my heart still races with every new tech challenge.

But hey, life isn’t just about work! My personal tech escapades have led me to set up a myriad of Kubernetes clusters:

• External Cluster: My digital playground for internet-facing experiments.
• Private Cluster: Crafting digital solutions for the home front.
• Semi-Private Clusters: Melding the personal with the community, these serve friends, family, and a few entrepreneurial ventures.

And the cherry on top? My “non-prod” cluster. It’s where imagination takes flight, ideas are tested, and yes, sometimes things break. But that’s all part of the journey!

Now, the million-dollar question: Why this blog? I’ve always been a silent advocate for Free and Open Source Software (FOSS), keeping my tech adventures close to my chest. But it’s time to share! Here, I aim to:

• Share lessons from the trenches of tech.
• Offer a window into my digital wonderland.
• Provide insights, musings, and (hopefully) helpful code.
• Spark that tech flame in some of you.

As the curtain rises on this digital chronicle, I invite you to join me. Whether you’re a seasoned tech guru, a budding enthusiast, or just plain curious, there’s a spot for you here. So, settle in, grab your drink of choice, and let’s kick off this journey together.