I wanted to try adding AI to a CLI tool to see how easy it would be. The idea was simple: instead of looking up command syntax, just ask the terminal in plain English.
Hi, I’m David. If you've been using Pulp for long enough, there's a good chance you may have encountered a bug I contributed. I worked on Pulp for many years while at Red Hat, from the beginning of the Pulp 3 back when it was just a proof of concept. Those early days were full of whiteboarding and discussions around which technologies to use (e.g. futures or asyncio?), whether to create a CLI or Web UI, and how to integrate Pulp 3 with products like Satellite and Ansible Galaxy.
Fast-forward to today, I now work at Microsoft on the Azure Core Linux team. And in a really interesting bit of serendipity, we've spent the past few years using Pulp to overhaul packages.microsoft.com, Microsoft's service for Linux package repositories. I've gone from developing Pulp full-time to running it as a user.
Writing documentation can often be a significant effort. Recently, I needed to document a new feature, the "Alternate Content Source". But where to start? The core information existed in a user conversation on Matrix. How could I turn that scattered information into structured, usable documentation efficiently? I decided to experiment with an AI tool, specifically NotebookLM, to see if it could streamline the process.
The starting point was straightforward. I took the raw Matrix conversation and uploaded it as a source into NotebookLM. I also added the existing pulpproject.org website as another source, hoping it would provide context and stylistic examples (Note: this specific detail about adding the pulpproject.org site comes from my process description, not the provided source text). My initial prompt was simple: "write me markdown docs from this user conversation". It produced the content for this pull requested.
In the ever-evolving landscape of software development, ensuring predictability and consistency in deployments has always been a challenge. Our team faced similar hurdles, especially when managing historical versions of repositories. We needed a solution that could help us recreate environments from specific points in time, ensure reproducible deployments, and track changes in package behavior over time.
Inspired by the success stories of Ubuntu Snapshots on Azure and the increased security and resiliency of Canonical workloads on Azure, we embarked on a journey to develop a feature that could address these challenges.
"Release fast, release often!" is not a metaphor, it is a mantra.
Pulp used to be a service mainly running on-premises as part of products with extremely long release cycles. About two years ago, we heard rumors to add highly volatile cloud service style installations to the mix. Because releasing a new version of pulpcore or any of its many plugins was a herculean task, the rumors were accompanied by very concerning sentences like: "We will run this service off of main branches of all the plugins." If that does not make you shiver, you can just stop reading here and go on with your happy life.