Argo CD / Automation, lifecycle, and trust / Lesson 8

Sync options and shared resource ownership

Read apply behavior, field ownership, and resource tracking before changing sync options.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish client-side apply, server-side apply, replace, and deletion choices conceptually.
Review shared-resource collisions without enabling destructive fallback behavior.

An option changes a specific operation contract

Argo CD sync options can alter how resources are applied, validated, pruned, or treated when shared. These are not universal repair switches. Parcel’s failure to update an immutable field differs from an ownership conflict or a missing CRD. Read the exact error and selected resource identity before changing options. Replace or force-style behavior can recreate resources and disrupt state or availability under its documented semantics. Server-side apply introduces field-management considerations; it does not make incompatible intent safe merely because another write mechanism is available.

Resource tracking is not the same as field management

Argo CD tracks which resources belong to an Application using configured supported mechanisms such as annotations or labels. Kubernetes field managers describe another aspect of how fields are managed. Shared labels, name collisions, generated copies, and multiple Applications can complicate ownership. A resource can appear associated with one application while another actor manages a field. Record the full identity and actual tracking mode. Do not delete an apparently extraneous object until its ownership and consumers are understood.

Fail visibly when another Application owns the resource

The FailOnSharedResource option can make a sync fail when a resource is already managed by another Application under documented detection. The fragment below illustrates that choice without enabling sync or changing any target. It is not a complete protection against every external writer or field conflict. Both Applications’ source and tracking definitions need review. A deliberate shared resource may belong in a separately owned Application or another explicit contract instead of competing independent declarations.

yaml A shared-resource collision-policy fragment

spec:
  syncPolicy:
    syncOptions:
      - FailOnSharedResource=true

This partial Application is not applied. It illustrates release-3.1 option semantics and does not inspect actual tracking, Kubernetes managedFields, permissions, or another controller.

Detect a declared ownership collision locally

The complete local model compares two declared Application resource sets and identifies their shared identity. It does not implement Argo CD tracking, discover live ownership, or decide which writer should win. A set intersection is only a diagnostic clue. The real solution needs an owner, reviewed source transition, compatible field behavior, and protection against duplicate side effects. Do not make a conflict disappear by stripping tracking metadata without understanding how subsequent reconciliation and pruning will interpret the object.

python A synthetic Application-overlap model

app_a = {("apps", "Deployment", "parcel-lab", "parcel")}
app_b = {("apps", "Deployment", "parcel-lab", "parcel"), ("", "Service", "parcel-lab", "parcel")}
shared = sorted(app_a & app_b)
print(shared)
print("review ownership" if shared else "no declared overlap")

Expected output

[('apps', 'Deployment', 'parcel-lab', 'parcel')]
review ownership

Only declared tuples are compared. No Application, managed field, label, annotation, or cluster is queried or changed.

Review one narrowly justified change

For each proposed option, explain the triggering error, intended behavior, known disruption, authority, and verification. Ignoring a difference affects comparison, while respecting ignored fields during sync requires its own supported behavior; those choices are developed separately. A dry-run exception for a missing kind does not prove the kind will exist when needed. Keep option precedence and per-resource annotations visible. Verify actual desired and observed identities after an authorized correction, and retain the prior evidence instead of applying a bundle of options until the operation turns green.

Common errors and fixes

Replace or force behavior is enabled for every sync failure.

Why it happens: Different schema, ownership, and lifecycle failures share an indiscriminate fallback.
How to fix it: Diagnose the exact resource and review a narrow compatible remedy.
Prevent it next time: Document disruption and recovery for each operation mode.

A shared tracking label is treated as complete proof of ownership.

Why it happens: Tracking metadata was read without its configured mechanism and other writers.
How to fix it: Review full resource identity, tracking mode, and field management.
Prevent it next time: Assign explicit ownership and avoid competing declarations.

Tracking metadata is removed to hide a collision.

Why it happens: The symptom is suppressed while reconciliation and pruning semantics become unclear.
How to fix it: Plan a reviewed ownership transition with all affected Applications.
Prevent it next time: Test retention, comparison, and deletion behavior at the correct scope.

Check your understanding

1. Two Applications declare the same Deployment identity. Does a matching manifest make the shared ownership harmless?

Show worked solution

Not automatically. Future edits, tracking, pruning, and operation options can conflict even while current bytes match. Assign ownership or a deliberate shared contract and review both source paths rather than assuming equality removes lifecycle risk.

2. Does server-side apply guarantee a valid update to an immutable field?