-
Notifications
You must be signed in to change notification settings - Fork 132
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
Refactor reconcilers and introduce v1beta2 API #435
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
v1beta2
is backwards compatible withv1beta1
. The only changes are to the.status
sub-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.url
in favor of.status.webhookPath
Stalled=True
condition withReconciling=True
andReason=ProgressingWithRetry
on retryable failureslastHandledReconcileAt
to.status
spec.interval
to periodically reconcile Providers and Receivers with their Secret references to surface config errors after initialisation.address
andproxy
summary
field (required by Slack and others)Controller changes:
Bug fixes included in this PR:
.status
updates instead of just.spec
&ReconcileAt
ReconcileAt
was not handled at all, even if some types were reacting to itStalled
condition was added even if the controller could recover on the next try