Merge branch 'main' into lfx-anushka

Author: FloorD

content/blog/lfx-chaos-testing-yash-agarwal/index.md

@@ -0,0 +1,80 @@
+---
+title: "Chaos testing the CloudNativePG project"
+date: 2026-01-05
+draft: false
+image:
+    url: yash.jpeg
+    attribution:
+authors:
+ - fdrees
+tags:
+ - lfx
+ - mentorship
+ - kubernetes
+ - postgresql
+ - litmus
+ - devops
+summary: "Meet the mentee: Yash Agarwal worked with the project maintainers on adding 
+chaos testing to CloudNativePG, as part of the LFX mentorship program." 
+---
+
+In the summer we wrote about how CloudNativePG was back for the September-
+October-November LFX term with [several projects for mentoring](https://cloudnative-pg.io/blog/2025-term3-lfx-cncf-mentorship/). One of them was 
+around Chaos Testing. 
+
+Yash Agarwal worked with mentors and CloudNativePG maintainers Gabriele Bartolini, 
+Marco Nenciarini, Francesco Canovai, and Jonathan Gonzalez, to enhance the 
+project's test coverage. Introducing LitmusChaos, a comprehensive chaos testing 
+framework, the team designed automated chaos experiments for common failure 
+scenarios, integrated them into CI/CD workflows, and collected observability 
+metrics like failover time and data consistency. I had a chat with Yash about 
+his work, and about how he got into Tech in the first place. 
+
+## Start at the beginning
+
+Yash's venture into programming started when he got introduced to Python in 11th 
+grade. He was always fascinated by technology, and got further inspired to pursue 
+a career as a programmer by his cousin Amit, a software developer.
+
+Today Yash is a full stack developer intern at Seeqlo, where he, among other 
+things, focuses on streamlining cloud operations and optimizing performance. 
+Based in Bengaluru, India, Yash is a member of Point Blank, a student-run tech 
+community dedicated to learning together. 
+
+He looks back at working with the CloudNativePG team as a "great learning experience". 
+They met twice a week for 30 minutes to discuss the progress of the project. 
+One thing that Yash says he learned is to have more patience. 
+
+## Chaos testing
+
+The new [chaos-testing repository](https://github.com/cloudnative-pg/chaos-testing) Yash worked on provides automated tools to validate 
+PostgreSQL cluster resilience under failure conditions. It combines two testing 
+approaches:
+
+* Jepsen Consistency Testing - Uses the famous Jepsen framework to perform 
+mathematical proofs of database consistency. It continuously runs database 
+operations (50 ops/sec) and validates that no data is lost or corrupted during 
+failures.
+* LitmusChaos Fault Injection - Uses LitmusChaos to simulate real-world failures 
+by repeatedly deleting the PostgreSQL primary pod (every 60-180 seconds), 
+forcing CloudNativePG to perform automatic failover.
+
+You can read more about the project in the repository's [README](https://github.com/cloudnative-pg/chaos-testing/blob/main/README.md). And, in case 
+you're curious, here's Yash's PR: https://github.com/cloudnative-pg/chaos-testing/pull/3 
+
+
+## Contributing to Litmus itself
+
+Yash wasn't able to find how to get the chaos engine to target the primary pods 
+since the appKind CloudNativePG uses isn't natively supported by Litmus. "I tried 
+many things, but when I tried AppKind as "cluster" it worked! I read the Litmus 
+code and found that there were some validations which prevented "Cluster" (capital 
+"C") from working. This behavior was not described in Litmus' documentation, 
+which meant I could submit a PR and prevent the next person from running into 
+the same issue!"
+
+## What's next?
+
+In the second half of his 3rd year, Yash is exploring opportunities in the field 
+of backend and DevOps. "I will surely try to contribute more towards CloudNativePG 
+when time permits!" You can follow Yash's work on [GitHub](https://github.com/XploY04).

content/blog/lfx-chaos-testing-yash-agarwal/yash.jpeg

@@ -0,0 +1,89 @@
+---
+title: "Sticking with Open Source: pgEdge and CloudNativePG"
+date: 2026-01-02
+draft: false
+image:
+    url: pgedge_cloudnativepg.jpg
+    attribution:
+authors:
+ - fdrees
+tags:
+ - helm
+ - ImageCatalog
+ - CNCF
+ - kubernetes
+ - postgresql
+ - open-source
+summary: "We talked to Matthew Mols, Sr. Director of Engineering at pgEdge, 
+about how CloudNativePG enables them to meet the requirements of their customers 
+using just open source." 
+---
+
+[Matthew Mols](https://www.linkedin.com/in/mmols/) is the Sr. Director of Engineering at pgEdge, a team of engineers and 
+entrepreneurs on a mission to make it easy to build, deploy and manage enterprise 
+grade applications at scale on Postgres. 
+
+Recently pgEdge announced their [CloudNativePG integration](https://www.postgresql.org/about/news/pgedge-announces-cloudnativepg-integration-simplifying-postgres-on-kubernetes-3166/) and them joining the 
+Cloud Native Computing Foundation (CNCF). 
+
+We had a chance to talk to Matt about their use of CloudNativePG.
+
+## Why CloudNativePG works for pgEdge
+
+Matt loves learning about customers' challenges with Postgres, and thinking about 
+how they can build or suggest tools and approaches to make their lives easier. 
+"I'm continually surprised by the different ways folks are leveraging Postgres 
+in their businesses."
+
+Matt's role is focused on developing tools that enable pgEdge's customers to 
+effectively deploy Postgres, whether that’s on Kubernetes, VMs, bare metal, or in 
+the Cloud. A lot of this work is centered around making it easier to use tools 
+together to meet the requirements of different kinds of customers. 
+
+"We are fully committed to open source and tend to utilize a combination of open 
+source extensions and tools that we've developed and released, like Spock for 
+multi-master (active-active) logical replication, combined with stable community 
+tools like CloudNativePG." 
+
+pgEdge uses CloudNativePG in their [Helm chart](https://docs.pgedge.com/pgedge-containers/), which allows users to deploy 
+active-active databases into multiple Kubernetes clusters, and keep them in sync. 
+
+## Getting started with CloudNativePG
+
+Before CloudNativePG, Matt and his team used other operators, and a mix of custom 
+Helm charts that leveraged Kubernetes primitives to deploy Postgres instances. 
+CloudNativePG's popularity and stability, and its acceptance into the CNCF, 
+confirmed that it was the right choice to switch to as the default.
+
+"Working with CloudNativePG has been really straightforward for us since we've 
+moved to it exclusively. In particular, the documentation is very well done, 
+with a combination of "start from here" examples, combined with in-depth guides 
+for every feature. Deploying Postgres comes with a lot of choices on specific 
+configuration, and it does a great job of laying out why you would choose from 
+one option or the other, with sensible defaults."
+
+Access to stable Service endpoints that point to the current primary instance 
+is the thing Matt mentions as "one of the most valuable aspects of deploying a 
+CloudNativePG cluster". Matt: "Outside of Kubernetes there are many tools you need 
+to integrate correctly to give that guarantee to applications and integrations." 
+pgEdge leverages these stable services to enable distributed databases across 
+multiple CloudNativePG clusters in different Kubernetes clusters, while relying 
+on automatic failover with standby instances in each region.
+
+In terms of roadmap, Matt is particularly excited about the recent introduction 
+of dynamic loading of PostgreSQL extensions, and some of the upcoming work to 
+extend that to the ImageCatalog CRD. "As Postgres has embraced containerization 
+more and more, this has been a challenging area to navigate, with growing image 
+sizes, dependency management headaches, and adherence to license requirements. 
+In particular, this is going to go a long way towards improving how we manage 
+supply chain risk in the Postgres community."
+
+## What's next?
+
+Matt looks forward to contributing back to the project in the future. "Our hope 
+is to look to contribute more capabilities that enable distributed deployment 
+with CloudNativePG, potentially as part of supporting the CNPG-I approach to 
+plugins." The goal is to make it easier to operate active-active databases that 
+span across multiple Kubernetes clusters, enabling better support for different 
+types of multi-region deployments. "Our thought is that it's best done through 
+CloudNativePG interfaces."