Operator pattern

Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components. Operators follow Kubernetes principles, notably the control loop.

Motivation

The Operator pattern aims to capture the key aim of a human operator who is managing a service or set of services. Human operators who look after specific applications and services have deep knowledge of how the system ought to behave, how to deploy it, and how to react if there are problems.

People who run workloads on Kubernetes often like to use automation to take care of repeatable tasks. The Operator pattern captures how you can write code to automate a task beyond what Kubernetes itself provides.

NOTE: The above is taken verbatim from https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

Proposal

We propose this change to make ODIM more easily adaptable by organisations/projects interested in ODIM but may not be willing to invest in redfish APIs and ODIM specific interfaces like odim_controller. These will let users automate tasks while using popular kubernetes interfaces( refer to details at URL above).

We want to propose operator(s) with the following types of functonalities be implemented:

• Cluster management related - These operators will do work related to kubernetes/ODIM application management. The operations will include but not limited to:
  • installing new/removing kubernetes node, 
  • scaling up and down the ODIM cluster
• operation related - These will translate kubernetes request sent by user to redfish request before passing these to ODIM. These operations may minimally include 
  • add/delete new BMCs, plugins
  • query inventory details 
  • make modifications to like creating/deleting volumes etc.
  • create event subscriptions
• reporting related - these operators will let users to extract reports from ODIM and push it to systems like prometheus/grafana.