Skip to content
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

(feat) CloudEvents #298

Merged
merged 1 commit into from
Jan 30, 2025
Merged

(feat) CloudEvents #298

merged 1 commit into from
Jan 30, 2025

Conversation

gianlucam76
Copy link
Member

EventSource can match CloudEvents over NATS/JetStream subjects.

EventReports in the managed cluster contains the matching CloudEvents. When EventReport instances are collected, they are processed in the management cluster. If all is successfull, EventReport is stored in the management cluster (with no matching cloudEvents, those are removed before storing it). The EventReport is updated in the managed cluster by removing the processed CloudEvents and setting the status to Processed.

If an error happens, EventReport in the managed cluster is not updated. So it will be fetched again and again the matching CloudEvents will be processed.

ClusterProfiles/Secrets/ConfigMaps created because of CloudEvents have two labels:

  1. eventtrigger.lib.projectsveltos.io/cesource containing the CloudEvent Source
  2. eventtrigger.lib.projectsveltos.io/cesubject containing the CloudEvent Subject

Resources created because of a CloudEvent are removed only in those scenario:

  1. EventTrigger is removed
  2. Cluster stops being a match for an EventTrigger
  3. EventTrigger.Spec.CloudEventAction is set to Delete

The last case is important. It means Sveltos identifies CloudEvents using Source,Subject pair.

@gianlucam76 gianlucam76 force-pushed the messging branch 2 times, most recently from 7090829 to 073e656 Compare January 29, 2025 15:42
EventSource can match CloudEvents over NATS/JetStream subjects.

EventReports in the managed cluster contains the matching CloudEvents.
When EventReport instances are collected, they are processed in the management
cluster. If all is successfull, EventReport is stored in the management
cluster (with no matching cloudEvents, those are removed before storing it).
The EventReport is updated in the managed cluster by removing the processed
CloudEvents and setting the status to Processed.

If an error happens, EventReport in the managed cluster is not updated.
So it will be fetched again and again the matching CloudEvents will be
processed.

ClusterProfiles/Secrets/ConfigMaps created because of CloudEvents have two labels:
1. eventtrigger.lib.projectsveltos.io/cesource containing the CloudEvent Source
1. eventtrigger.lib.projectsveltos.io/cesubject containing the CloudEvent Subject

Resources created because of a CloudEvent are removed only in those scenario:
1. EventTrigger is removed
2. Cluster stops being a match for an EventTrigger
3. EventTrigger.Spec.CloudEventAction is set to ``Delete`

The last case is important. It means Sveltos identifies CloudEvents using
Source,Subject pair.
@gianlucam76 gianlucam76 merged commit 1f74552 into main Jan 30, 2025
4 checks passed
@gianlucam76 gianlucam76 deleted the messging branch January 30, 2025 09:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant