Operator repo selection

[tianyin]

There are discussions on Slack about the repo selection.

It's indeed non-trivial to select repos that can cover multiple different dimensions.

What I suggest we to do is to collect as much meta-information as possible so we can have an informative selection together.

Currently, I don't have much information to make a call or comment based on
https://github.com/xlab-uiuc/k8s-operator-bugs/blob/main/k8s-operator-repos.md

What I hope to see is more like a spreadsheet (you can use google spreadsheet) that summarizes many potential repos so we can just sit together and select.

[tylergu]

Crawl

I did a crawl over github. I searched for repositories with "operator" in their name or descriptions and written primarily with golang. Then I sorted them by number of stars and only kept the top 50 repos. There are a number of them are not actually k8s-operators but rather some frameworks for writing operators, so a manual check is done to exclude these out.

Result: https://docs.google.com/spreadsheets/d/1_3-SlBRJO0Gtj6gt2Go1cOi4iRHdeBquoV-04Yel74A/edit?usp=sharing

Capability Level

This is a concept given by Operator Framework (https://operatorframework.io/operator-capabilities/). There are five capability levels, from high to low:

• Auto Pilot: Horizontal/vertical scaling, auto config tuning, abnormal detection, scheduling tuning
• Deep Insights: Metrics, alerts, log processing and workload analysis
• Full Lifecycle: App lifecycle, storage lifecycle (backup, failure recovery)
• Seamless Upgrades: Patch and minor version upgrades supported
• Basic Install: Automated application provisioning and configuration management

Problem with Capability Level

The difficulty of dealing with capability level is that developers do not label their operator with a certain Capability Level. Only operators on OperaturHub have a capability level tag, and OperatorHub only hosts a very small subset of operators in the wild. If we really want to use Capability Level as one of our metrics, we have to manually inspect every operator's source code, determine their capability, and decide which Capability Level they fall into. This I believe is prohibitively expensive.

Current Metadata we have

The github crawl gives us the

• Owner
• Description
• # forks
• # stars
• # watches
• # open issues
• # closed issues

With some manual effort of reading projects' description, I included the type of application they operate (some of them do not deal a particular application, but serve as a utility), and very incomplete information of their development status.