Argo-cd: Pruning heredity

Created on 20 Feb 2019  路  3Comments  路  Source: argoproj/argo-cd

Hello everyone,

i want to create a scenario where people can change kubernetes objects without any privileges using argocd.
Also i don't want them to have privileges in argocd.
Everything should be controlled by the files in our git repo, because we are using pull requests to allow changes to it.

The problem here is that one needs privileges to create argocd applications and projects.
This can be solved by creating a project and application that watches a directory of my repo where crd files can be put. When a user uploads a application crd to the directory, then my argocd application creates the app that has now been uploaded and this newly created app then creates the kubernetes objects.

For e.g. like this:

deployer-project.yaml

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: argocd-objects
spec:
  description: argocd-objects
  destinations:
  - namespace: '*'
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  sourceRepos:
  - ssh://xxx.git

deployer-app-projects.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-projects
spec:
  project: argocd-objects
  source:
    repoURL: ssh://xxx.git
    targetRevision: HEAD
    path: system-cicd/projects
  destination:
    server: https://kubernetes.default.svc
    namespace: system-cicd
  syncPolicy:
    automated:
      prune: true

deployer-app-apps.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: argocd-apps
spec:
  project: argocd-objects
  source:
    repoURL: ssh://xxx.git
    targetRevision: HEAD
    path: system-cicd/apps
  destination:
    server: https://kubernetes.default.svc
    namespace: system-cicd
  syncPolicy:
    automated:
      prune: true

now one can drop files in the repo under the specified paths like this:
system-cicd/projects/system-monitoring.yaml

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: system-monitoring
spec:
  description: Monitoring related stuff
  destinations:
  - namespace: '*'
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  sourceRepos:
  - ssh://xxx.git

system-cicd/apps/prometheus-operator.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-operator
spec:
  project: system-monitoring
  source:
    repoURL: ssh://xxx.git
    targetRevision: update-argocd
    path: system-monitoring/prometheus-operator
  destination:
    server: https://kubernetes.default.svc
    namespace: system-monitoring
  syncPolicy:
    automated:
      prune: true

Creating new objects like this is working great.
When an application crd yaml gets removed from the directory, then it is also removed from argocd.
But the kubernetes objects - pods, svc... stay, even though the application had pruning activated.

It seems like argocd is correctly pruning the application that was removed but the pruning isn't passed down to the objects created by the application.

How can i solve this, so that, when an app crd is removed from the repo all the pods are also deleted?

Argocd version: 0.11.1
Kubernetes version: 1.13.2

Most helpful comment

When an application crd yaml gets removed from the directory, then it is also removed from argocd.
But the kubernetes objects - pods, svc... stay, even though the application had pruning activated.
It seems like argocd is correctly pruning the application that was removed but the pruning isn't passed down to the objects created by the application.

This isn't documented, but in order to achieve this behavior, the application spec in git should have the following finalizer:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-operator
  finalizers:
  - resources-finalizer.argocd.argoproj.io

In normal deletes through the Argo CD API server, when it gets a delete request for an application, it does a normal kubernetes delete, but right before the deletion, it decides whether or not to add the finalizer, depending if cascaded deletion is requested.

Your use case is to have cascaded deletion, but since the Argo CD API server is not handling the delete, you miss out on this logic. Adding this finalizer will achieve your desired behavior.

All 3 comments

When an application crd yaml gets removed from the directory, then it is also removed from argocd.
But the kubernetes objects - pods, svc... stay, even though the application had pruning activated.
It seems like argocd is correctly pruning the application that was removed but the pruning isn't passed down to the objects created by the application.

This isn't documented, but in order to achieve this behavior, the application spec in git should have the following finalizer:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-operator
  finalizers:
  - resources-finalizer.argocd.argoproj.io

In normal deletes through the Argo CD API server, when it gets a delete request for an application, it does a normal kubernetes delete, but right before the deletion, it decides whether or not to add the finalizer, depending if cascaded deletion is requested.

Your use case is to have cascaded deletion, but since the Argo CD API server is not handling the delete, you miss out on this logic. Adding this finalizer will achieve your desired behavior.

resources-finalizer.argocd.argoproj.io

I wish we named this cascade-delete.argocd.argoproj.io

Thank you so much!
This is working great. I'll close this issue then

Was this page helpful?
0 / 5 - 0 ratings