# Pelorus Design ###### tags: `Pelorus` # 2022-09-27 * Decision #A Goal - eng and user feedback * quay pulls * operator install metrics * github issues, discussion etc. #B k8s support #C Koveyor membership #D Custom metrics #E community operator A: M(9) K(10) W(10) = 29 B: M(8) K(7) W (6) = 21 C: M(3) K(7) W (7) = 17 D: M(3) K(9) W (8) = 20 E: M(7) K(9) W(9) = 25 # Community Operator Migi & Kevin going offline to brainstorm separately * https://github.com/KevinMGranger/pelorus/blob/helm_chart_operator_prepare/charts/README.md # HOMEWORK * informal discussion 2022-09-27 * homework due on October 6th # Pelorus Helm Operator Design 2022-10-12 See also: https://github.com/KevinMGranger/pelorus/blob/helm_chart_operator_prepare/charts/README.md ## GOAL: Community Operator install of Pelorus why? * A more user friendly and Openshift standard path to install * Pelorus will be MORE visisible by adding it to the community catalog * We can track the number of Pelorus installs ### Constraints: * maintain helm install while operator work is in progress? * YES * How: library helm charts and symlinks may make this * Helm "Library" Charts these can just be sets of templates that are pulled in by other charts. This means we can have shared logic that is used by both traditional helm and the operator-sdk (in case we need to do slightly different approaches) * must work out of master branch * merge early, merge often. Use feature flags if necessary. * long-lived diverging branches are painful _at best_ * k8s's considerations? * yes.. but 1st pass will be scoped to pelorus only and not invoking the granfa and prometheus operators ## High level Breakdown - [ ] Prepare charts for operator-sdk compatibility (e.g. doesn't support nested charts) - [ ] Developer instructions and workflow - [ ] Generate "starter" operator with operator-sdk generator - [ ] ~~[Draw the rest of the owl](https://i.kym-cdn.com/photos/images/newsfeed/000/572/078/d6d.jpg)~~ - [ ] Update prow CI for an operator based install - [ ] OLM based install on OpenShift - [ ] Start simple: just have a "Pelorus" CRD and reuse existing values.yml structure - [ ] Update Documentation - [ ] Ensure seemless install and upgrade / updates - [ ] Deprecate helm install / and /charts - [ ] Ensure we understand how to get Pelorus listed as a community operator and is in the catalog. ## Individual work items ( copy from high level breakdown ) BD1 - [ ] Prepare charts for operator-sdk compatibility (e.g. doesn't support nested charts) - [ ] Move `exporters` under /charts (not nested under `pelorus` chart) - [ ] Move things to library charts (to support next step) - [ ] Create an alternate chart (i.e. `/charts/pelorus-operator`) with an alternate values.yml (to lean on generation as much as possible) - [ ] Create UI for user input - [ ] learn how this works - [ ] continuously verify with **C**I that we aren't breaking this for existing users - [ ] Developer instructions and workflow - [ ] Find a way to deploy operator out of the source tree and automate process to easy development. - [ ] Generate "starter" operator with operator-sdk generator - [ ] tag this step so we have a baseline for future operator-sdk versions BD1 - [ ] Update prow CI for an operator based install - [ ] OLM based install on OpenShift - [ ] Start simple: just have a "Pelorus" CRD and reuse existing values.yml structure - [ ] adjust the values so the generated CRD's are up to date w/ the values - [ ] Once we know the above works, make 1 CRD per exporter type (not backend) Change the "exporters" chart to be a singular exporter (caveat: right now the RBAC is scoped across all exporters. Maybe we make that part of a common "pelorus core" resource (or whatever we call it)) - [ ] Deprecate helm install / and /charts - [ ] for $warning time - [ ] Ensure we understand how to get Pelorus listed as a community operator and is in the catalog. ## Questions for Later - [ ] if we want automatic / seamless upgrades, how do we automate updating from the latest image? - [ ] there's a way to do this with ImageStreams, right? A polling mechanism? or is it only webhooks? - [ ] perhaps the operator can (optionally) deploy a cron job that checks - [ ] how do we automate updating the _operator_ too?