Argo-cd: Support kubectl replace instead of apply

[epa095]

Summary

Could it be possible to have argocd use kubectl replace instead of kubectl apply when applying/replacing resource?

Motivation

We have some custom resources which can be quite big, at least larger than 256Kb, which is the limit for the metadata in k8s, and kubectl apply puts the whole configuration into last-applied-configuration as explained for example here. We use argocd to push all our other k8s resources to the cluster, so it would be nice if we could use it for these resources as well.

Proposal

A flag per project.

[alexec]

Could you use force mode?

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[gnu300]

I have the same need of that feature in a different context.
i am trying to automate my OpenShift cluster configuration via ArgoCD. With cluster configuration i mean:

• IDP/oauth configuration
• RoleBindings
• Storage (PV) for image-registry and rook csi
• Resource allocation for kube-/system-reserved
• ....

I actually thought that this is a use-case for ArgoCD but if i am trying to sync as an example the oauth yaml i get the following error:
Operation cannot be fulfilled on oauths.config.openshift.io "cluster": the object has been modified; please apply your changes to the latest version and try again
This error occurs when you are not referencing to the latest version (=resourceversion) within your yaml. This behaviour is equivalent to "oc apply -f oauth.yaml", therefore Kubernetes/OpenShift has the command "oc replace...".
Forcing this is not an option because then oc/kubectl/argocd would try to delete the resource first and create/apply it again. This might be useful for Pods/Deployments and so on, but not for IDP and other global cluster configuration, this would lead to instability within the cluster and probably degrade the availability.

[nickma82]

Could you use force mode?

As this mode (at least in some cases) first deletes the resource just to add the new one, there are use cases where you cant do that.

[Cuball0]

A replace could probably also solve the issue where we have a wrong resourceVersion in our manifest in Git compared to the resourceVersion in the cluster.

When the resourceVersion gets changed (in this case because of a new automatic Deployment) it's not in sync with the version in Git and it blocks the sync process in ArgoCD.

See the error :

kubectl failed exit status 1: The deploymentconfigs "demo" is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

[gnu300]

I got my use-case working, i documented it here https://www.reddit.com/r/openshift/comments/ew5de7/argocd_apply_openshift_cluster_config/fg4klk1?utm_source=share&utm_medium=web2x

[cabrinha]

I'm running into this issue when trying to apply large ConfigMaps that are JSONs for grafana:

ConfigMap "grafana-dashboard-my-dashboard" is invalid: metadata.annotations: Too long: must have at most 262144 characters

Using a pre-sync delete hook did not help.

[jessesuen]

@alexmt do we support annotating a resource to do force=true like we have for validate=false ? If so, I wonder if that would satisfy this use case

EDIT:

As this mode (at least in some cases) first deletes the resource just to add the new one, there are use cases where you cant do that.

Just read this comment, so I dont think it solves it fully.

[cre8ivejp]

Any chances of this being implemented by this year?

[muzcategui1106-gs]

+1 on this issue. In my case --force did not help. I have also tried to use presync hooks to delete the object before but Argocd fails to apply it due to the annotations as apply will always create the annotations.

Seems like the only viable option is to do a replace but I am happy to be proven wrong

[servo1x]

This would also be useful for CRDs that are very large.

[gymlt]

+1 on this issue.
ConfigMap "grafana-dashboard-redis-haproxy" is invalid: metadata.annotations: Too long: must have at most 262144 bytes

[gnu300]

+1

[qingkunl]

+1. This is a blocking issue for us.

[yydzhou]

+1, same issue here.

[rumstead]

@jessesuen @alexmt are there any docs around force mode? I brought this up on slack the other day.

I want to be able to automatically “kubectl apply --force” my Kubernetes manifests so I don't have to force sync via the UI when a label or something immutable changes. I saw the SyncOptions and tried adding “--force”, “force=true”, and “Force=true” but none seemed to work. I then stumbled across SyncStrategy. I was able to set this on the Application Resource and it seems to work but I want to make sure this is the best way to do it.