Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Migrate to using kubebuilder. #41
Note that the authorization server use case is a bit tricky as kubebuilder assumes that the Kubernetes API Server is available. To circumvent this, I kept a portion of the old webhook server code to function as a standalone server.
Most of the new files are generated by kubebuilder, as is the directory structure. This includes the Dockerfile and Makefile.
Also, secrets should be automatically generated by the server and the webhooks automatically registered (in the non-standalone case).
Apologies for the massive change but there wasn't a gradual way to do this.
Two sticking points...
I forgot to add the --authorization-mode flag to that mode's example yaml. Will fix shortly.
Second, I'm unsure what Docker repo to use. Didn't want to leave the old pointer, as it would be out of date, but the new one is not publicly shared. Should I just up the version tag on the old repo and you can rebuild/push?
Good question. I think some of that depends on how the vision for the project develops.
Personally, I'm leaning toward making sure we write something general enough that the authorization server can effectively become a consumer of the project's API. This would give us a builtin litmus test to make sure we are choosing the right kinds of abstractions.
If it turns out the differing requirements of the standalone server complicate the CI/CD pipeline or add unnecessary friction, we could explore splitting it to its own repo.