Roadmap/Next Target Feature

[pthomison]

Figured we might want to start some kind of tracking for any features / improvement that we want to start jamming on next!

Just listing out the state of the union; it feels like we have the following areas fairly straightened out

• CI/CD
• K8S Unit Testing (tho I'm sure we have a lot more work in terms of getting testing coverage everywhere)
• Standard Controller functionality
• Consuming existing frameworks (ie controller-runtime) to abstract out low level shenanigans with the k8s API
• Reuse of k8s-client & config objects throughout the controller lifetime

Some ideas that I've had so far, but don't feel too opinionated in terms of priority:

• golang module refactor: I think we can probably reduce most of our functionality down to a module or two, just to reduce the amount you need to look at/comprehend for the tool
• Metrics exposure: The controller-runtime has a built in metrics-server and we could look into emitting our own custom metrics (ie # of namespaces updated, etc)
• (super easy/nitpicky one) Update the pkg folder to be internal: (reference layout)[https://github.com/golang-standards/project-layout]; AFAIK pkg should have modules that are intended to be consumed by outside parties and internal is where you store your modules that are soley for consumption by your program
• Support for leader election in the helm chart (enabling leader election w/ controller-runtime should be really easy on the golang side)

[pthomison]

Curious what you are thinking feature wise and we should take on next @ejether !

[pthomison]

Also @sudermanjr curious to your take on any of the controller design and/or priorities. All of my learning has been via trying weird stuff with kubebuilder, so its very likely I may be dragging along some bad practices from my experiments haha

[ejether]

Honestly not sure where to take it at this point but I see two categories of work

• QOL Improvements like versioning, builds, releases, refactor, standard style
• Feature development

QOL faffing is easy to justify on this project. Features are hard to say because it's not really being used.

That said, here's what I think over all:

• I support leader election as a top priority so that it can be run with more than one replication.
• @sudermanjr and I discussed a CRD here instead of the config map but couldn't get to a sensible format that was better than the ConfigMap. Either through CRD behavior or just the config parser, better schema checking for the input would be a real nice to have.
• I also like the metrics idea. I didn't think about that. Could be useful for monitoring unexoected changes.
• Refactors are always good. I don't have any opinions about internal or pkg I'm for whatever you want to do here.
• I'm interested in a little cleaner release and artifact storage thing and clean up the helm chart versioning