Welcome to Red Hat Connect for Technology Partners. This guide provides instructions on the changes needed in your operator to become a certified operator. For more information on Building your Operator please visit: Operator-SDK. The purpose of this guide is to help further develop and test the functionality of your operator. Once testing is complete you can complete certification by going to our Partner Guide.

• Before you get started, make sure you go through the Pre-Requisites section.

​

You can think of the Operator Capability Level model as a visual sizing guide as to which toolkit you should use to build your operator. Once you've decided which phases (or feature sets) are being targeted, this model helps you decide which framework(s) you can use to achieve that goal.

Use Cases ideal for operator development

• stateful applications (such as databases)

• clustered or high-availability applications (clustered databases, key-value stores such as etcd, in-memory cache clusters such as Redis)

• multiservice applications (an application which needs dependent services to come online first)

• microservices (numerous small components that together make up a cohesive product or app)

Use cases less ideal for operator development

• stateless apps (most web apps or front-ends)

• infrastructure/host agents (monitoring agents or log forwarders)

Operators are intended for use cases where there are more complex or stateful applications. Kubernetes already handles stateless applications (with pods and deployments) and host agents (Daemonsets) rather well. With that being said, those "less than ideal" use cases can still benefit from an operator. The ideal toolkit for building an operator for stateless applications and host agents is either Helm or Ansible, both of which allow for a quick, simple development cycle using the operator-sdk. This provides you with the ability to leverage the marketplace that's built into OpenShift 4.x and provide end users with a one click install experience on OpenShift.

​

​