# Jira Stories Scratchpad

A scratchpad for potential new Jira stories/epics/tasks to be created for various things

## CatalogSource V1 work

### Proof of Concept
- Explore options for configuring Package and BundleMetadata CR admission criteria on the apiserver
- GraphQL sidecar container for serving bundle data (replaces `BundleMetadata` CR)
- The purpose of this is to evaluate a method that reduces the number of CREATE requests sent to the apiserver in anticipation that this *could* be a concern
- Potential Tasks:
- Update the GraphQL PoC to have functionality to add bundle/catalog data
- Update the current CatalogSource V1 PoC to run the GraphQL PoC as a sidecar for storing/serving bundle/catalog data. (might be best to do this on a new branch/fork to have some degree of separation between approaches)
- Extend the current Operator Controller prototypes to use the new CatalogSource V1 API surface (?)
- Test the viability of this new API approach early by creating some form of integration
- Is this something we want to do as part of the PoC?

### Alpha (?)
I was thinking it might be nice to go ahead and create tickets for things we *know* we are going to have to do regardless of the route we take after the PoC so this is a stab at that:
- Refine the CatalogSource controller to be more production-like
- Update CatalogSource CR to communicate state via `.Status.Conditions`
- Update CatalogSource controller to properly handle various error states
- Refactor CatalogSource controller to follow a similar format to that of rukpak or oria controllers (keeps controller implementations across OLM v1 components consistent)
- Ensure ownership is set properly on child resources for easy resource cleanup on CatalogSource deletion
- Update the Operator Registry or OF/api types to include the appropriate functions to be used in multiple different scenarios (i.e library usage and CR field type usage)
- Update CRs to use these updated types
- Write unit tests
- Can probably break this down into smaller chunks
- Write e2e tests
- Can probably break this down into smaller chunks
- Create GitHub Actions
- Unit tests on PR/merge
- E2E tests on PR/merge
- go fmt/vet & git diff checks on PR/merge
- automated release on tag push using goreleaser
- Explore configuring the manifests generation to be a bit better
- Currently there are a lot of manual changes that need to be made with the manifests (mostly related to RBAC) as the controller and API implementations are modified. We should probably try to use kustomize to make this process as automated as possible (i.e just have to run a `make` target)
- Transfer ownership of anik120/rukpak-packageserver to Operator Framework GitHub Organization (?)
- Is this the name we want? Do we want to split the apiserver and controllers into separate repos? Is this something we want to do as part of the alpha release/implementation process?
- Follow-up: Create Operator Framework Quay images
- Create the first alpha release :tada:

## Operator-SDK tech debt
- Add some form of PR auto-merge when `approved` and `lgtm` labels are added.
- This can be done in a few different ways (prow, GitHub Actions, etc.) and would help prevent PRs sitting around for days/weeks after getting the required approvals
- Simplify the image refresh action
- This action is *very* complex and difficult to troubleshoot when problems occur. This doesn't happen often but when it does it would be nice if this process was easier to understand.
- Re-evaluate the release process and see if there is a way we can automate this as much as possible - ideally the only manual step is to push a tag.
- Update GitHub Actions to set Go version based on go.mod
- This would simplify our Go version bumps a bit :)
- Implement the EUS/LTS model (?)
- has this been ironed out and decided on? A good bit of work could come from this
- Update `make bindata` to generate and update OLM versions everywhere and run the validation script
- Update the `olm-check` GitHub Action to run properly on release branches
- It currently has an incorrect branch configuration and therefore has never actually ran

## Telescopia --> controller-runtime
- [Upstream] Start & facilitate discussion around getting Telescopia/dynamic cache moved into controller-runtime
- More stories would be created depending on the outcome of this