Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Apply optimizations for handling of condition checks #32123

Merged
merged 7 commits into from Nov 1, 2022
Merged

Apply optimizations for handling of condition checks #32123

merged 7 commits into from Nov 1, 2022

Commits on Nov 1, 2022

  1. don't lose checks from refresh-only plan 

    If there are no changes, then there is no reason to create an apply
graph since all objects are known. We however do need the walk to match
the expected state structure. This is probably only cleanup of empty
nested modules and outputs, but some investigation is needed before
making the full change.

For now we can store the checks from the plan directly into the new
state, since the apply walk overwrote the results we had already.
    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    b61c02d View commit details
    Browse the repository at this point in the history

  2. changes are mutated during apply

    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    fa4c652 View commit details
    Browse the repository at this point in the history

  3. normalize empty CheckResults fields in stateV4 

    Ensure that empty check results are normalized in state serialization to
prevent unexpected state changes from being written.

Because there is no consistent empty, null and omit_empty usage for
state structs, there's no good way to create a test which will fail
for future additions.
    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    eae246c View commit details
    Browse the repository at this point in the history

  4. fix log mesage

    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    19152e7 View commit details
    Browse the repository at this point in the history

  5. only add NoOp nodes with conditions 

    ONly add NoOp changes to the apply graph if they have conditions which
need to be evaluated.
    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    eb88ccb View commit details
    Browse the repository at this point in the history

  6. avoid re-writing state for noop applies 

    We need to avoid re-writing the state for every NoOp apply. We may
still be evaluating the instance to account for any side-effects in the
condition checks, however the state of the instance has not changes.
Re-writing the state is a non-current operation, which may require
encoding a fairly large instance state and re-serializing the entire
state blob, so it is best avoided if possible.
    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    ffe2e39 View commit details
    Browse the repository at this point in the history

  7. use key data from plan method for apply

    @jbardin
    jbardin committed Nov 1, 2022
    Copy the full SHA
    efd7715 View commit details
    Browse the repository at this point in the history