Ability to suspend an argo application

[andye2004]

Firstly, thanks for a great tool. It's made life much easier for us!

There are times where I want to 'suspend' an application. That is, I want to temporarily delete it from the cluster and then re-add it. Currently I have to delete the argo application completely and then re-add it into argo. It would be useful if there was a feature where I could suspend it in argo and that would delete the app in the cluster BUT keep the argo application definition ready to re-sync.

[jannfis]

Hm. You could have your application definition residing in a dedicated definition modeling the app of apps patterns with auto-sync disabled on the parent.

Then you could cascade-delete the application in question ("child app"), and if you want it back, you just re-sync the parent application.

[andye2004]

@jannfis, thanks for the follow-up. I'll have a think on this for a few days and we'll maybe have a discussion internally re your suggestion. Doesn't feel quite right though - I'll get back to you.

[dcharbonnier]

This "status" of disabled application could be really useful for development. If I have two projects using the pattern app of apps : project1 : app1, app2 project2 : app1, app2, app3

I would be able (on my development machine) to stop working on project1 and start working on project2 with 2 clicks (or one commit) I don't see a use-case for a production environment.

[jeacott1]

+1 - I'd love to see a stop, or suspend button for each application in the UI. It would make regular but intermittent workloads much easier to manage. - to extend the notion, a schedule of suspend/resume could be added to only run workloads during certain times and then auto shut them down would be especially nice. Autoscalers would then auto reduce nodes and thus running costs.

[danielepanzeri]

+1

[Kampe]

+1 - people with app of apps pattern with auto sync on need a way to pause both the parent and child application.

[hilenko]

+1

[ghost]

+1

[davem-git]

+1

[nikcollins]

+1

[marcelofabricanti]

+1

[armenr]

+1

[vmironichev-nix]

+1

[tanalam2411]

+1

[achetronic]

+1

[Cave-Johnson]

+1

Not for a prod deployment but for when debugging a dev cluster, pausing deployments would be super useful

[JBogossianKH]

+1 ❤️

[Va1]

+1

[kschjeld]

+1 Much better than commenting out contents of YAML-file if you want to temporarily disable

[zoop-btc]

+1 would be useful

[Mahesh-Gunda-Maersk]

+1 very useful.

[filipdadgar]

+1, would love to see this feature!

[elendis]

+1

[meetzuber]

+1, It will be help full in production - DR cluster use case. We can disable the application in production cluster and start it in DR cluster in case of DR failover. Will reduce downtime.

[cedws]

Can you not spam +1s? Just leave a thumbs up reaction on the issue.

[armenr]

Can you not spam +1s? Just leave a thumbs up reaction on the issue.

+1, he's right.

[medoedoff]

+1

[mat-work]

+1

[agusserraetendo]

+1

[eaceaser]

+1

[crenshaw-dev]

I want to make sure we're all +1'ing the same feature request.

Please react to indicate which feature you want:

• ❤️ Delete all resources in the app
• 🚀 Scale down all scalable resource in the app
• 👀 Something else (please comment, too)

Please no more +1s without describing your use case. The enthusiasm is appreciated, but keeping the thread tidy is good too. 😄

[canghai118]

I want to make sure we're all +1'ing the same feature request.

Please react to indicate which feature you want:

• ❤️ Delete all resources in the app
• 🚀 Scale down all scalable resource in the app
• 👀 Something else (please comment, too)

Please no more +1s without describing your use case. The enthusiasm is appreciated, but keeping the thread tidy is good too. 😄

* ❤️ Delete all resources in the app (It's better to have an option to keep the PVC or PV, so the entire applicaiton state can be resumed)

[jeacott1]

@canghai118 for me both options would be useful actually, I want to be able to minimise resource usage without trashing configMaps etc so a Scale down option would also be very useful for things that can scale down. I would also like to sometimes "Delete all resources in the app" without having to delete the app config itself. I think this is probably what most people want so you can push 'go' again and not have to reconfigure the app each time.

[jannfis]

I think this should be possible meanwhile, although it's not exposed through the UI or CLI (yet): https://argo-cd.readthedocs.io/en/stable/user-guide/skip_reconcile/

This should effectively implement the requested feature?

[crenshaw-dev]

@jannfis I think the issue title is too vague. Seems like most folks on the thread are interested in a per-app scale-down mechanism.

[crenshaw-dev]

Ooh. With the new actions enhancements in 2.8, we should do something like this:

-- Loop over resources from the Application status. Scale down Deployments and StatefulSets.

actions = {}

if obj.status == nil then
    return actions
end

for _, resource in ipairs(obj.status.resources or {}) do
    if resource.health.status ~= "Missing" and (resource.kind == "Deployment" or resource.kind == "StatefulSet") then
        action = {}
        action.operation = "patch"
        action.resource = {}
        if resource.group == nil or resource.group == "" then
          action.resource.apiVersion = resource.version
        else
          action.resource.apiVersion = resource.group .. "/" .. resource.version
        end
        action.resource.kind = resource.kind
        action.resource.metadata = {}
        action.resource.metadata.name = resource.name
        action.resource.metadata.namespace = resource.namespace
        action.resource.spec = {}
        action.resource.spec.replicas = 0
        table.insert(actions, action)
    end
end

return actions

[sav116]

• 1

[crenshaw-dev]

Is anyone up for trying to implement the actions-based solution? I'd be happy to help.

[crenshaw-dev]

For the two folks who answered that they want "delete all resources in the app," let's track that feature request here: https://github.com/argoproj/argo-cd/issues/6079

This issue (#3039) can track "scale down all scalable resources."

[jnkxcel]

For my use case I work at a utility and they heavy hand the password, rotation is a pain, I used to just kubectl scale --replicas=0. But with Argo control it self heals. Which I love but now I have to remove my deploy, update password and then redeploy. Not huge lift but cumbersome for prod facing apps. This is specific to K8s plugin external-dns connecting to infoblox. I manage the external-dns plugin via an app of apps deploy so I just have to remove one line entry and argo sync so again not huge lift.

Just would be so much nicer to have scale down feature. similar thread that lead me here https://github.com/argoproj/argo-cd/issues/11451

[crenshaw-dev]

Sounds like in your case you'd need both to both scale down and disable self-heal.

[jnkxcel]

Thank you I will go that route, still fairly new in the argo game.

[MioOgbeni]

Hi, how is this issue going? It would also be awesome to be able to set scale down of scalable resources by on/off office hours, or by scale down/up cron. It could be configurable by completely new ArgoCD resource or directly in Application resource.

[MaxWinterstein]

Hi, how is this issue going? It would also be awesome to be able to set scale down of scalable resources by on/off office hours, or by scale down/up cron. It could be configurable by completely new ArgoCD resource or directly in Application resource.

@MioOgbeni you might wanna have a look at https://keda.sh/ and its cron scaler.

[dcharbonnier]

an alternative, and maybe better solution is to use a generator, with a generator you can enable / disable and application with your own rules : https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Plugin/

[jnkxcel]

I found workaround if you need temp solution, just make application manual sync, select the deployment object, select to edit it, in replica key:value shift value to 0. This will effectively shift application to 0 pod/replicas. when you want to scale back up you can either manual sync, it will bring back to previous replica, or update code then refresh and sync and this will bring pods/replicas back up. This is Janky but you kind of have temp scale down method.

[evanstucker-hates-2fa]

How to disable applications, lol.

Ensure that your ApplicationSet syncPolicy.automated.prune: true, then:

$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    renamed:    applications/matomo/config.json -> applications-disabled/matomo/config.json
    renamed:    applications/matomo/values.yaml -> applications-disabled/matomo/values.yaml

Note that this may cause gaps in your git history if you move files back and forth. Maybe a smarter person would use symlinks? This is just a joke/hack, but it works. Let's get a real feature added to do this!

[jmichaelthurman]

Yes. I need a feature equivalent to flux suspend kustomization to be able to pause healing of applications by automation that are stood-down during infrastructure maintenance windows.

For flux apps, I'm using KEDA to launch a job to issue commands & patch scaledObjects in the K8s cluster.

[crenshaw-dev]

@jmichaelthurman wouldn't that just be "disable self-heal" and maybe "disable auto-sync"? If you need to prevent even imperative syncs, you could also add a sync window.

[xpxNPE]

hi

another use case : test/validation environment.

when we are not using our test / validation environment, the "powers that be" delete every application to free up ressources. so when we need the environement again we have to redeploy everything even if there was no change since the last deployment.

having a way to restart the application from the argoCS UI without havaing to redeploy them would be great