-
Notifications
You must be signed in to change notification settings - Fork 152
Refactor reconcilers and introduce v1beta2 API #435
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
e5a9b99 to
cca289d
Compare
69a93ae to
6a696ad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested that the commit status still works with this update
68180be to
26f84f1
Compare
a2473ae to
e2ed630
Compare
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
Signed-off-by: Stefan Prodan <[email protected]>
- Extensively document the various Receiver types, their validation mechanics and their caveats. - Move various things around a bit to ensure we follow the same flow as the rewritten source-controller specs. - Explicitly document the expected format of the Secret. - Various other small rewordings and fixes. Signed-off-by: Hidde Beydals <[email protected]>
Signed-off-by: Hidde Beydals <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So much stuff here! Refactoring looks really nice ✔️
502a898 to
b07d09d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Great job @stefanprodan @darkowlzz @hiddeco! 👏 👏 👏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left comments about two minor fixes in the docs.
Overall LGTM!
Plus addressing of a couple of nits. The following must still be picked up at a later moment: - More sections need to be moved from "working with" to "writing a ..." - Documentation flow can likely be improved once the sections have been moved. - Technical description of the behavior of the Provider types could be improved, this should be easier to do when everything has the same format. Signed-off-by: Hidde Beydals <[email protected]>
This PR refactors notification-controller to implement the new unified standards of Flux controllers (closes: #376) and documents the API usage in the new format (closes: #378, fixes: #433).
The API version
v1beta2is backwards compatible withv1beta1. The only changes are to the.statussub-resource and.status.conditions, which the controller will upgrade on its own. No user intervention is required besides bumping the version in the custom resource definitions.API changes:
Receiver.status.urlin favor of.status.webhookPathStalled=Truecondition withReconciling=TrueandReason=ProgressingWithRetryon retryable failureslastHandledReconcileAtto.statusspec.intervalto periodically reconcile Providers and Receivers with their Secret references to surface config errors after initialisation.addressandproxysummaryfield (required by Slack and others)Controller changes:
Bug fixes included in this PR:
.statusupdates instead of just.spec&ReconcileAtReconcileAtwas not handled at all, even if some types were reacting to itStalledcondition was added even if the controller could recover on the next try