avoid package globals

[groob]

this package relies on several global variables(example http.Client). For testing and maintainability, it would be better to refactor the code that relies on global state.

[kelseyhightower]

Agreed. Lot's of refactoring is in order. This was a weekend project that ended up growing a bit larger than expected and may turn out to be generally useful. The next couple of weeks will be about cleaning up the docs and improving code quality.

I'll also be deciding if this will grow into a true open source project or serve as a working example of how to build custom Kubernetes controllers. Today I'm happy if people can learn something from this repo and I encourage people to fork it and built sometime more awesome.

[kelseyhightower]

@groob Also thanks for taking the time to review the code and file this issue. I'll keep this open as a promise to address your feedback over the next few weeks as part of a larger code review and clean up process.

[bshi]

I'll also be deciding if this will grow into a true open source project or serve as a working example of how to build custom Kubernetes controllers. Today I'm happy if people can learn something from this repo and I encourage people to fork it and built sometime more awesome.

Thanks for the great example project, @kelseyhightower. We have a use-case that requires cert-manager to monitor all (save perhaps a blacklisted set) namespaces for certificate objects. Supporting this use case probably adds a lot of complexity that reduces the educational value of codebase. In your eyes, is this a fork situation or is the feature in question compelling enough to be worth integrating?