notification-controller posted all outgoing Alertmanager alerts with
"timestamp" label, effectively preventing grouping alerts related to the
same resource and forcing users to configure a separate alert receiver
with `send_resolved: false`.
This changes it to instead set "startsAt", which was previously set
(automatically by Alertmanager) to alert posting time. "endsAt" remains
unset, as we have no way of figuring that out but the reconciliation
interval of the resource that generated the alert, which can currently
only be found out by making a Kubernetes API round-trip.
Note that this requires users to adapt alert templates that relied on
.Labels.Timestamp.
Signed-off-by: Timur Demin <me@tdem.in>
- Update README.md to point to v1beta3 spec docs.
- Remove provider testdata which had old API version and is no longer
used in any test.
- Update Provider v1beta2 spec docs to use Alert v1beta2.
- Update Provider v1beta3 spec docs to use v1beta3 API in all the
code snippets.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
For backwards compatibility with v1beta2 Provider, add .spec.interval
with deprecation marker.
Interval was an optional field in v1beta2 with internal default. Only
the users who had explicitly set intervals would have encountered this
incompatibility error after upgrade.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
v1beta3 API for Alert and Provider makes them static objects, removing
the status subresource and spec fields that are relevant to dynamic
objects with reconcilers.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
In order to streamline the docs across all controllers, the CRD spec
file names are pluralized. This lets us better automate docs generation
from CRD specs.
refs fluxcd/website#1577
Signed-off-by: Max Jonas Werner <mail@makk.es>
Receiver .status.url was deprecated in v1beta2 API and replaced with
.status.webhookPath. Remove it from v1 API and all references to it.
Signed-off-by: Sunny <darkowlzz@protonmail.com>
This commit bumps the Receiver API version to v1 in preparation of
the Flux GitOps GA milestone
(https://fluxcd.io/roadmap/#flux-gitops-ga-q1-2023).
We are now actively maintaining two versions of the notification API
group in parallel: v1 which currently only holds the Receiver kind and
v1beta2 for all other kinds.
Since we haven't run into this situation before, I had to change the
way we expose the API docs in ./docs/api: The directory now has
sub-directories for each active API version. Therefore we need to
change our scripts in the website repository to take this change into
account so that we expose both API group version at
https://fluxcd.io/flux/components/notification/api/. This change is
implemented in https://github.com/fluxcd/website/pull/1427.
refs #436
Signed-off-by: Max Jonas Werner <mail@makk.es>
This has been introduced in #482 but we actually want this feature to
only be available in v1 of the API. A follow-up PR will re-add this to
the v1 API.
Signed-off-by: Max Jonas Werner <mail@makk.es>
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 <hello@hidde.co>
- 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 <hello@hidde.co>