Describe the bug
I've been working on adding priorityClassName to our applicationset so a certain number of deployments/daemonsets have an higher priority and are scheduled above other ones
For that, I'm employing something similar to https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/templates/argocd-applicationset/deployment.yaml#L52L54
Once I merge that change to our test applicationset, argocd picks it up and initiates the sync but never progresses or finishes, nor any service was modified.
Reverting the commit led to argocd go back into a stable state
To Reproduce
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: XXXXX-base-deployments
namespace: argocd-system
spec:
goTemplate: true
generators:
- matrix:
generators:
- matrix:
generators:
- git:
repoURL: "https://github.com/XXXXX/XXXXX-test.deployments.git"
revision: HEAD
directories:
- path: "base/*/*/*"
- git:
repoURL: "https://github.com/XXXXX/XXXXX-test.deployments.git"
revision: HEAD
files:
- path: "{{ .path.path }}/values.yaml"
- clusters:
selector:
matchLabels:
argocd.argoproj.io/secret-type: cluster
matchExpressions:
- key: cluster-name
operator: In
values:
- "{{if lt 0 (len .argo.clustername)}}{{index .argo.clustername 0}}{{else}}na{{end}}"
- "{{if lt 1 (len .argo.clustername)}}{{index .argo.clustername 1}}{{else}}na{{end}}"
strategy:
type: RollingSync
rollingSync:
steps:
- matchExpressions:
- key: priority
operator: In
values:
- phase-0
maxUpdate: 100% # if undefined, all applications matched are updated together (default is 100%)
- matchExpressions:
- key: priority
operator: In
values:
- phase-1
maxUpdate: 100% # if undefined, all applications matched are updated together (default is 100%)
- matchExpressions:
- key: priority
operator: In
values:
- phase-2
maxUpdate: 100% # if 0, no matched applications will be updated
- matchExpressions:
- key: priority
operator: In
values:
- phase-3
maxUpdate: 100% # maxUpdate supports both integer and percentage string values (rounds down, but floored at 1 Application for >0%)
- matchExpressions:
- key: priority
operator: In
values:
- phase-4
maxUpdate: 100% # maxUpdate supports both integer and percentage string values (rounds down, but floored at 1 Application for >0%)
template:
metadata:
name: "{{ .nameNormalized }}-{{ .path.basename }}"
finalizers:
- resources-finalizer.argocd.argoproj.io
labels:
priority: "{{ index .path.segments 2 }}"
spec:
project: default
source:
repoURL: "https://github.com/XXXXX/XXXXX-test.deployments.git"
path: "{{ .path.path }}"
targetRevision: HEAD
helm:
passCredentials: true
valueFiles:
- "/common/values.{{ .path.basename }}.yaml"
- "./values.yaml"
destination:
name: "{{ .nameNormalized }}"
namespace: "sre-{{ .path.basename }}-system"
priorityClassName: "system-node-critical"
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
ignoreDifferences:
- group: external-secrets.io
kind: SecretStore
jsonPointers:
- /spec/provider/vault/auth/kubernetes/mountPath
- group: networking.k8s.io
kind: Ingress
jsonPointers:
- /spec/rules/0/host
- /metadata/annotations/external-dns.alpha.kubernetes.io~1aws-region
Expected behavior
for sync to finishes and services now include priorityClassName: "system-node-critical" in their spec
Checklist:
argocd version
.Describe the bug I've been working on adding priorityClassName to our applicationset so a certain number of deployments/daemonsets have an higher priority and are scheduled above other ones For that, I'm employing something similar to https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/templates/argocd-applicationset/deployment.yaml#L52L54 Once I merge that change to our test applicationset, argocd picks it up and initiates the sync but never progresses or finishes, nor any service was modified. Reverting the commit led to argocd go back into a stable state
To Reproduce
Expected behavior
for sync to finishes and services now include
priorityClassName: "system-node-critical"
in their specScreenshots
Version
EKS cluster running argo-cd is on EKS 1.26 eks.4 Target cluster running services is EKS 1.27 eks.3
Logs