#6946 Notifications IDL Pull request opened by iaroslav-ciupin Tracking issue Why are the changes needed? The goal of this PR is to address following use cases: Flyte OSS 1. I am new to notifications and I want to test my delivery configuration for the first time before creating any runs. I should use flyte-sdk or UI to call

DeliveryConfigService.SendTestNotification

in which I should provide my configuration and required template data. Endpoint will synchronously compile notification and send a corresponding notification(webhook, email, Slack). 2. Once I am happy with my delivery configuration, I can create a one-off run with it. I should use flyte-sdk or UI to call

RunService.CreateRun

and put my previously tested delivery configuration into

RunSpec.notification_settings.InlineRule

field. This will store all necessary notification settings in run's RunSpec. When run completes, ActionService will send a ActionStatus with the same RunSpec to

action_statuses

Redis Stream. ActionStatus consumer will forward this message to

notifications

stream. Our notification consumer will pick this message and will compile & send a notification using same code as in step 1. 3. Once I see that my runs are triggering notifications as expected, I may want to update my deployed triggers with my tested notification settings. For this, I need to adjust existing triggers' RunSpec and add notification settings to it as in step 2 and re-deploy my tasks. Union-only 1. If I want to send notifications for all runs(triggered and manual) in a certain domain, project, for certain tasks, I should call

DeliveryConfigService.SaveDeliveryConfig

and

RuleService.SaveRule

endpoints via flyte-sdk or UI to create a persisted rule that will automatically inject notification settings for all runs that match those rules. This means everytime

RunService.CreateRun

endpoint is called, it will inject notification settings into its RunSpec if we have a rule that matches it. We can have all notification rules cached in memory(we don't expect huge amount of rules created by our users, I would say hundreds) so that in the average case it should not affect

RunService.CreateRun

latency. For Flyte OSS, "persisted settings" APIs will return 5xx unimplemented and

RunService.CreateRun

with notification_settings non-empty rule_id will also be rejected. What changes were proposed in this pull request? How was this patch tested? Labels Please add one or more of the following labels to categorize your PR: • added: For new features. • changed: For changes in existing functionality. • deprecated: For soon-to-be-removed features. • removed: For features being removed. • fixed: For any bug fixed. • security: In case of vulnerabilities This is important to improve the readability of release notes. Setup process Screenshots Check all the applicable boxes • I updated the documentation accordingly. • All new and existing tests passed. • All commits are signed-off. Related PRs Docs link •

main

• #6583 • #6946 👈 flyteorg/flyte