align guidelines with the framework principles#104
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the operator guidelines documentation to better align mutation usage with the framework’s reconciliation and data extraction model, clarifying how to avoid encoding “observation” into mutations.
Changes:
- Tightens guidance to discourage using live cluster state to drive a resource’s own mutations.
- Adds explanation of the execution order: mutations run before same-resource data extraction.
- Clarifies intended use of data extractors for passing observed state from earlier resources to later resources.
| Mutations operate on the desired object, not the server's current state. A mutation should be a pure function of the | ||
| owner spec and other static inputs available at build time. It should never try to read the resource's live cluster | ||
| state to decide what to write. |
There was a problem hiding this comment.
The statement that a mutation should be a "pure function of the owner spec and other static inputs available at build time" conflicts with the framework’s supported pattern where a later resource’s mutation can depend on data extracted from an earlier resource during the same reconcile (extractors run after a resource is applied and make data available to subsequent resources). Consider rewording to emphasize "no reads of the same resource’s live cluster state" / "deterministic given owner spec plus any previously extracted inputs", rather than limiting inputs to build-time only.
No description provided.