(WIP) - Update to latest operator-sdk and Code Refactor #4
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains quite a bit, and is not fully finished. At the very least I either want to lock away the event hook functionality behind a feature gate, finish a base implementation, or throw it away entirely before this is merged. But seemed worth while to go ahead and open the PR so you can see the direction I went with some things. I'm thinking the
tenancyKindAPI change I mentioned could either get added into this branch or maybe on a separate PR.The reason so many files are "changed" is that the latest
operator-sdkswitched to using go modules instead of vendoring dependencies. So the entire vendor directory has been removed in this PR. Kind of ruins the Github experience lol.Here is a brief mile-high overview of the changes so far in this branch:
MakefileOne extra thing I'm curious about. We talked about not wanting to place owner references on the
Tenantobjects to avoid accidental deletion when aMultiTenancygets deleted. But if I'm understanding the code currently (and what is still implemented on this branch) is the "cleanup" that happens at the end of aMultiTenancyreconcile will remove pods and configmaps for just that reason. So while the Tenant will not get deleted, the pods and configmaps will be in a deletion loop until theMultiTenancyobject is recreated. Do we want to maybe adjust this behavior as well?