Chapter 10. Getting Involved
All of the components in the Operator Framework, including the Operator SDK, Operator Lifecycle Manager, and Operator Metering, are still in the early stages of their lifespans. There are a variety of ways to contribute to their development, ranging from something as simple as submitting a bug report to becoming an active developer.
One of the simplest ways of interacting with both users and developers of the Operator Framework is through its Special Interest Group, or SIG. The SIG uses a mailing list to discuss topics including upcoming release information, best practices, and user questions. The SIG is free to join from their website.
For more direct interaction, the Kubernetes Slack team is an active community of users and developers. The “kubernetes-operators” channel in particular covers topics related to this book.
The Operator Framework GitHub organization contains the project repositories for each of its components. There are also a variety of supplemental repositories, such as the Operator SDK Samples repository, that further help with Operator development and usage.
Feature Requests and Reporting Bugs
One of the simplest ways, albeit an extremely valuable one, of getting involved with the Operator Framework is to submit bug reports. The framework project teams use GitHub’s built-in issue tracking to triage and fix outstanding issues. You can find the tracker for each specific project under the Issues tab on the GitHub project page. For example, the Operator SDK’s issue tracker can be found at the Operator Framework GitHub repo.
Additionally, the project teams use the issue tracker to track feature requests. The New Issue button prompts submitters to select between bug reports and feature requests, which are then automatically tagged appropriately. Submitting feature requests provides a wide variety of uses cases and helps drive the project direction based on community needs.
There are a few general principles1 to keep in mind when submitting a new issue:
-
Be specific. For bugs, provide as much information as possible about the running environment, including project versions and cluster details. When possible, include detailed reproduction steps. For feature requests, start by including the use case being addressed by the requested feature. This aids in the feature prioritization and helps the team decide if there is a better or existing way to fulfill the request.
-
Keep the scope limited to a single bug. Multiple reports are easier to triage and track than a report of a single, multifaceted issue.
-
Try to select the applicable project. For example, if the issue specifically applies to working with OLM, create the issue in that repository. For some bugs, it’s not always possible to determine where the problem is originating from. In those cases, you can choose the most applicable project repository and let the team triage it appropriately.
-
Use an existing issue if one is found. Use GitHub’s issue tracker’s search ability to see if a similar bug or feature request is found before creating a new report. Additionally, check the list of closed issues and reopen an existing bug if possible.
Contributing
Of course, if you’re comfortable working with code, contributions to the source code are appreciated. There are current instructions for setting up a development environment in the developer guide. Be sure to review the latest contributing guidelines before submitting any pull requests.
For reference, the repositories for the three primary Operator Framework components are as follows:
If you’re not comfortable coding, you can still contribute by updating and fleshing out the project documentation. The “kind/documentation” label for issues identifies outstanding errors and enhancement requests.
Sharing Operators
OperatorHub.io is a hosting site for community-written Operators. The site contains Operators from a wide variety of categories, including:
-
Databases
-
Machine learning
-
Monitoring
-
Networking
-
Storage
-
Security
The community provides automated testing and manual vetting for Operators featured on this site. They are packaged with the necessary metadata files to be installed and managed by OLM (see Chapter 8 for more information).
You can submit Operators for inclusion in OperatorHub.io via pull requests to the Community Operators repository. Check out this OperatorHub.io page with the latest submission instructions, including packaging guidelines.
Additionally, OperatorHub.io provides a way to preview how your CSV file will appear once it has been accepted and is hosted on the site. This is a good way to ensure that you have entered the proper metadata fields. You can find out more on the Operator Preview page.
The Awesome Operators repository keeps an updated list of Operators that are not hosted on OperatorHub.io. While these Operators have not been vetted in the same way as those hosted on OperatorHub.io, they are all open source, with their corresponding GitHub repositories listed.
Summary
As an open source project, the Operator Framework thrives on community involvement. Every bit helps, from participating in the mailing list conversations to contributing code for bug fixes and new features. Contributing to OperatorHub.io also helps promote your Operators while growing the ecosystem of available functionality.
1 See example issues here and here.