Proposal: Shared Resource Ownership

[avarei]

I had a little discussion with @davidmdm that I would like to continue here.

At the Moment Yoke does not change resources it did not create in the release context of the specific release.

But in some situations It can be benificial to have multiple CRs manage a single Resource or for an existing resource to be partiall in partially added to management

This could be a resource

• which only needs to exist once but is a dependency for each
• where each CR manages different kinds of fields

By setting ownerReferences to a resource that is release specific we ensure the shared resource is not garbage collected, when another owner is deleted until all ownerReferences have are deleted (for this reason blockOwnerDeletion should be considered with extra care)

By using server-side apply with a fieldManager that is specific to a given release the API Server detects and automatically prohibits conflicting applies.

This would make the yoke metadata fields obsolete.

When a release is deleted the managedFields would remain unless cleaned up.
Yoke could potentially use a finalizer on the releases' secret or the ATC CR to clean up the managedFields section on all resources it was a manager for and orphan them.
It would also be possible to apply an empty resource like this which would remove all fields only managed by this resource.
here's an example for the latter variant:

k create svc clusterip --tcp=80 --tcp=8080 test --dry-run=client -oyaml | k apply -f - --server-side --field-manager=yoke/namespace/release1
k create svc clusterip --tcp=80 --tcp=8081 test --dry-run=client -oyaml | k apply -f - --server-side --field-manager=yoke/namespace/release2
k apply -f - --server-side --field-manager=yoke/namespace/release1 <<EOF
apiVersion: v1
kind: Service
metadata:
  name: test
  namespace: default
EOF

The Service is created with port 80 and 8080, then 8081 is added and with the third command the field-manager yoke/namespace/release1 is removed, as well as port 8080.

heres an example how this could look like from the perspective of the shared managed resource

apiVersion: v1
kind: Service
metadata:
  ownerReferences:
  - apiVersion: apps/v1
    kind: Secret
    name: yoke.abc
    uid: abc123
  - apiVersion: apps/v1
    kind: Secret
    name: yoke.def
    uid: def456
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          f:app: {}
      f:spec:
        f:ports:
          k:{"port":80,"protocol":"TCP"}:
            .: {}
            f:name: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
          k:{"port":8080,"protocol":"TCP"}:
            .: {}
            f:name: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
        f:selector: {}
        f:type: {}
    manager: yoke/namespace/name1
    operation: Apply
    time: "2025-06-08T21:20:50Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:labels:
          f:app: {}
      f:spec:
        f:ports:
          k:{"port":80,"protocol":"TCP"}:
            .: {}
            f:name: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
          k:{"port":8081,"protocol":"TCP"}:
            .: {}
            f:name: {}
            f:port: {}
            f:protocol: {}
            f:targetPort: {}
        f:selector: {}
        f:type: {}
    manager: yoke/namespace/name2
    operation: Apply
    time: "2025-06-08T21:20:59Z"
  name: test
  namespace: default
  resourceVersion: "60392"
  uid: 959a5d48-2c8a-4cac-b610-1a58d4bc6780
spec:
  clusterIP: 10.105.216.15
  clusterIPs:
  - 10.105.216.15
  internalTrafficPolicy: Cluster
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: "80"
    port: 80
    protocol: TCP
    targetPort: 80
  - name: "8080"
    port: 8080
    protocol: TCP
    targetPort: 8080
  - name: "8081"
    port: 8081
    protocol: TCP
    targetPort: 8081
  selector:
    app: test
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

[avarei]

Regarding the handling of managedFields if the release is deleted:

Orphaning the fields vs Removing them:
I think if a release considers itself an owner in the ownerReferences it should delete it's fields

If it just enhances the resource, for example by adding some labels to it, it should not consider itself an owner and it should therefore orphan its fields on deletion.

Actually removing fields would allow for some fancy things like a ArgoCDPlugin resource which could potentially, add a sidecar container to an existing argocd installation and clean it up once the CR is deleted.

If we were to agree that deletion of managedFields should be dependant on the release being a manager for the resource, then I am not sure how to determine that we consider ouselfs owner or not.

[davidmdm]

Okay. I have some thoughts and concerns about this approach.

There are two key concepts:

• ownerReferences
• fieldManagers

Owner References

Owner references allow associate dependent objects together, and when a dependent has no more owning references it gets GCed by Kubernetes.

It also allows ArgoCD to create nice graph tree structures for its UI.

Internally it is used for the ATC. CRs are all owned by their airways, and allows yoke to provide a readiness check for those resources.

In core yoke, resources are not owned by another meta resource. There is an argument that they could be owned by their revision secret but something about that seems unconvincing to me.

Regardless, I am not sure what the owner-reference would serve for us. Even if we were to associate a flight's resources to its revision secret, this may create issues with cross-namespace flights, as owner-references don't work cross-namespace.

I am also unclear as to what value we are trying to gain out of using owner-references.

Field Managers / Server-Side Apply

Field Managers and server-side apply allow many actors to share a resource by attributing ownership on a per field basis.

This seems really appealing to me. If instead of using labels to track release ownership, which locks a resource to belonging to one specific release and disallows two releases from declaring the same resource, we could use field managers.

• every yoke apply release would use some computable field-manager: yoke:namespace/release (assuming we there are no character restrictions on field managers).
• if a release b conflicts with release a, it will fail during dry-run and the user will have the choice to either:
  • fix their values to not conflict
  • use the -force-conflicts flag
• when a release is deleted we:
  • remove the manager from the managedFields
  • if there are no yoke managers left, remove the object.

I suggest we not dabble with deleting fields as this could create instability.
Although it may be possible to send an empty request with server-side apply and the kubernetes api server would remove fields if possible... TBD. If that works we could remove fields via that mechanism and it should be safe and not too complicated to implement.

TL;DR

It is unclear to me if managing owner-references buys us anything beyond using field-managers.

Using field-managers and leaning on server-side apply seems to add value and make yoke more kubernetes native.
Things that we need to figure out:

• Can we use any characters in a field-manager name?
  • How do we encode a release into the manager name safely?
• Can we use server-side apply with an empty resource object to safely remove fields on deletion?

[avarei]

I do aggree that using ownerReferences in core yoke feels off and unintuitive. the alternative you proposed appears very promising to me:

• when a release is deleted we:
  • remove the manager from the managedFields
  • if there are no yoke managers left, remove the object.

Though I would think that this strategy (at least regarding deletion) maybe should be primarily considered for cli flights, since ATC and yokecd flights are leveraging ownerReferences and can depend on k8s' GC.

Regarding:

Can we use any characters in a field-manager name?

I could not find any so far. I just used can@123.we/use-anything?🤔 as a field manager name and the api server was fine with it. though I did notice that it appears to have a max length:
fieldManager: Too long: must have at most 128 bytes