argoproj / argoproj/notifications-engine

Support annotation selector in default subscription

Open
#377 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
334
Forks
217
PR merge metrics
No merged PRs in 30d

Description

## The Problem
Previously, I used the `application.instanceLabelKey: argocd.argoproj.io/instance` configuration to have `argocd.argoproj.io/instance=my-ops-repo` labels on my ArgoCD Applications.

By doing this, I was able to restrict the default subscriptions to all the applications in my main repo by using `selector: argocd.argoproj.io/instance=my-ops-repo`.

In ArgoCD 3.0, annotation based tracking is [strongly recommended](https://argo-cd.readthedocs.io/en/v3.0/user-guide/resource_tracking/) and is [now used as the default](https://argo-cd.readthedocs.io/en/stable/operator-manual/upgrading/2.14-3.0/#use-annotation-based-tracking-by-default).
Therefore, following the recommended changes would break this selector and my notifications.

To remedy this, `annotation+label` can be used "for informational purposes" and to support tools that require it.

## There's a workaround, why bother changing?
I would prefer to follow the emphasized default. The notifications engine seems to be the only component that currently prevents me from making the switch.

Given that ArgoCD Notifications is, as the name suggests, an official project, basic use cases shouldn't require switching to a sub-par solution meant for tools that didn't bother updating yet. Imo, the notifications engine should remain a first-class citizen staying up to date with changes to the upstream ArgoCD project and actively supporting them.

## Proposed solution
Add an `annotationSelector` field to the `DefaultSubscription`. Since plain `=` matching will not work anymore due to the new format containing significantly more information (e.g. `my-ops-repo:argoproj.io/Application:argocd/myapp` instead of just `my-ops-repo`), some kind of other filtering methods will have to be introduced. A `contains` or Regex-based one would do just fine.

The syntax could follow the [PromQL matching operators](https://prometheus.io/docs/prometheus/latest/querying/basics/#instant-vector-selectors):

> - `=`: Select labels that are exactly equal to the provided string.
> - `!=`: Select labels that are not equal to the provided string.
> - `=~`: Select labels that regex-match the provided string.
> - `!~`: Select labels that do not regex-match the provided string.

Given the "exactly equal" operator being `=`, this would both remain backwards compatible and feel familiar to engineers in this space while supporting my use case and many more.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating DefaultSubscription and the existing default-subscription selector handling in the notifications engine. Compare how current label selectors are parsed and applied, then define how an annotationSelector and its matching operators should behave; done means default subscriptions can filter annotation-based Argo CD tracking values without breaking existing selectors.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
backend, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.