With COVID-19 impacting operations everywhere, and therefore reducing opportunities for making live public announcements, Kubernetes SIG apps co-chair Matt Farina had to take to the CNCF mailing list to introduce the cloud native community to a new hub for CNCF artifacts.

The CNCF Hub is currently in pre-alpha stadium, but aspires to become a central place for Kubernetes users to find packages and configurations. Currently, those interested can for example find ways to install apps via the Helm Hub, security best practices and configurations through the Cloud Native Security Hub, and Operators in the OperatorHub, which can make things quite tricky.

Project maintainers are in a similar boat, since the current structure means that every project with artifacts worth sharing has to look into setting up a central infrastructure itself. And while this doesn’t necessarily have to bother the CNCF right now, it could very well become an issue in the future. 

After all, the Operator Framework has been proposed to become part of the CNCF, which would leave users with two officially endorsed projects to search through when needing to install applications, should it be approved. Something not really agreeing with the foundation’s mission to make cloud native computing easier.

To change that, a group of CNCF members including Farina, “representatives from the Operator Framework, KUDO, and Helm” and CNCF executive director Dan Kohn, got together at CloudNativeCon North America last November to discuss the idea of a less fractured approach. The initial specification describes the new hub as “designed to be one hub for all the CNCF projects that provide applications for end-users”.

It takes some learnings from the more established projects, for example in regards to look and feel, stating that the current layouts aren’t scalable and shouldn’t be considered. The first accessible iteration is therefore rather clean looking, with a simple search bar to look through the currently included 1053 packages, and a short list of recently added packages below.

Unsurprisingly, it still has a long way to go until the project is able to realise all aspects of the initial brief. According to the Hub’s GitHub repo, Helm support is currently still being worked on with more projects to follow. The final vision sees the project being responsible for the software part as well as a clearly defined process to add, update, and remove artifacts, and what it calls “operational responsibilities” to make sure the project doesn’t break anything relying on it.

How exactly this is going to be handled doesn’t seem to be completely clear yet, since for example it’s still up in the air if the Hub is meant to become a sandbox project or if a working group would be a better option to move it along. But the feedback over the coming weeks will probably paint a clearer picture of that.