In 2016, CoreOS hired Antoine Legrand (@ant31).

Antoine is an incredible engineer and a huge asset to the Kubernetes community; you may recognize him from many contributions, but most people probably would be familiar with a little project he started called Kubespray.

The first time I met Antoine, he had hacked together a demo of packaging up and storing Kubernetes resources into Quay. A fair bit after the initial demo, we decided it was worth pursuing for realsies and I helped Antoine through the process of making his demo a production grade feature for all Quay users. The general idea was to take the existing docker registry protocol and extend it to support more than just containers.

We called it CNR.

CNR, which stood for Container Native Registry, was an awful name, so shortly after we rebranded it to App Registry. The code was developed in the open, with weekly stand-ups in Kubernetes SIG Apps. This is actually where I met a bunch of incredible people in the Kubernetes community – basically everyone that worked in the Helm ecosystem. One of the obvious gaps we felt the project could fill was the distribution of Helm charts and at the time Helm had just added a plugin system. So, naturally, we built one.

The project had initial traction, but eventually the flame died out. There were numerous reasons: no one had time to work on the project full-time, it was written in Python instead of Go, Helm plugins were insufficiently powerful enough at the time to get the user experience we needed, and we had intentionally left authentication and storage as an exercise to the reader if you weren’t using Quay (which was closed source at the time). Regardless, some Quay users still use the plugin to this day.

Fast forward to today –

The docker registry specification has been donated to OCI and now there are more than just Kubernetes resources and Helm Charts floating around in the cloud-native ecosystem. As a community, we’ve realized that there’s this super convenient place to store our containers, but where does everything else go? Enter the OCI Artifact specification. The technical oversight committee for OCI just voted to approve its existence last week. It would appear that everyone is happily making progress to the world Antoine and I had envisioned years earlier…

Things can never be that simple.

As it stands today, the artifact specification is empty. Why? Because there are already two competing strategies on how to actually leverage OCI to store artifacts: ORAS and CNAB-to-OCI. In addition, it’s not quite clear where the line in the sand should be drawn in terms of what artifacts should be stored; taken to its logical conclusion, registries could just end up becoming a more complicated API for an object-store.

If you’d like to know the gory details about what’s going on you have two options: come to NYC and buy me many beers or join the upstream OCI discussions. You should be scared because this is going to affect absolutely everyone’s workflows in the future and if we get no feedback, you’ll be stuck with our shit.

Huge thanks to everyone that’s been a part of this journey over the years: