Actually it's better than I expected.

Cases:

• I modify resource A and watch A. How can I tell when I've observed
  my update, assuming I'm not the only actor?

The modification gives you back a ResourceVersion, which you can compare
(via equality) with RVs coming down your watch. Unfortunately you'd have to
expand this to compare via < to handle the general case where you have to
restart your watch--we currently claim that you cannot do this comparison,
although in practice it is currently safe if you confine yourself to a
single resource type.

• I modify resource A and resource B. How can I tell when I've
  observed both updates, assuming I'm not the only actor?

Same answer, just tracking RV per-resource.

• I modify resource A and resource B. How can I tell when the
  controller managing resource B has observed the update to resource A?

No general way at the moment.

• I create resources A, B, ..., Z. How can I tell when I've observed
  the creation of all of those resources, assuming I'm not the only actor
  (e.g., some resources might quickly be deleted by another agent)?

Same as first two answers.

• More concrete: I'm the ReplicaSet controller. How can I ensure that
  I update ReplicaSet status with the most up-to-date pod status in a HA,
  master-elected configuration, and am not?

I'm not 100% sure I follow the question, I think the ending is garbled?
But if you meant something like what I expect, I think we can extend the
precondition concept to support this.

/subscribe

/sub

Somewhat related: kubernetes/kubernetes#34363

Fixed my email-garbled comment above.

One more - preconditions on deletion and other actions. A resourceVersion precondition on delete, for example.

resourceVersion precondition on delete

Would be very useful. Right now there is a race between delete and any other operation that updates the object.
E.g. a controller that owns an object (has a controller owner reference pointing to it) cannot safely delete it because something else may change ownership concurrently. I don't know if it is an issue that happens in practice in kubernetes codebase but it is an issue for Custom Resource controllers.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/lifecycle frozen

/remove-lifecycle stale

Hi, is there any plan for this? Thx!

One more - preconditions on deletion and other actions. A resourceVersion precondition on delete, for example.

For those following along at home, we have this now.

I'd like to update my answers above considering the large amount of change the system has undergone.

• I modify resource A and watch A. How can I tell when I've observed
  my update, assuming I'm not the only actor?

Record the metadata.generation returned; when you observe and update with a generation >= that one, you've observed your change.

• I modify resource A and resource B. How can I tell when I've
  observed both updates, assuming I'm not the only actor?

Same answer, just tracking RV per-resource.

• I modify resource A and resource B. How can I tell when the
  controller managing resource B has observed the update to resource A?

We rely on the controller author to do something useful like record the observed generation.

• I create resources A, B, ..., Z. How can I tell when I've observed
  the creation of all of those resources, assuming I'm not the only actor
  (e.g., some resources might quickly be deleted by another agent)?

We don't offer a way to detect an "after" relationship with a deletion. But we do now offer both UID and RV deletion preconditions, so folks doing the deletion no longer risk losing a change accidentally.

• More concrete: I'm the ReplicaSet controller. How can I ensure that
  I update ReplicaSet status with the most up-to-date pod status in a HA,
  master-elected configuration, and am not?

I have unpublished drafts on individual object locking for controllers-- it involves an annotation with an "I hold lock X" assertion + a webhook which does a consistent read of the lock object to confirm.

Thanks for the updates.

Is metadata.generation updated for all resource types?

It is not 100% automated, so it's possible for an individual resource to do it wrong, but we would treat that as an important bug.

Closing old issues that are unlikely to be useful any further.

Closing old issues that are unlikely to be useful any further.

I actually believe this issue is still useful, we need documentation on the types of guarantees we provide for which API calls and what combinations of API calls one would need to make in order to preserve data integrity at a certain level.

To some extent, this issue served as documentation.

Can we turn it into documentation? Or re-open it as a request to write such documentation?

Can we turn it into documentation? Or re-open it as a request to write such documentation?

Yeah that makes sense.

For some more context, read: Life Beyond Distributed Transactions: An apostate's opinion

/reopen

@sftim: Reopened this issue.

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/transfer website
/sig docs
/kind documentation

/retitle Document API architectural approach for soundness and consistency

Some parts of this work might end up in https://k8s.dev/docs/

/language en
/wg api-expression
/triage accepted
/lifecycle frozen
/priority important-longterm

/remove-priority backlog

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted