-
Notifications
You must be signed in to change notification settings - Fork 41
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Read resource state after each Create and Update operation to avoid s…
…purious diffs (#3042) The code change in this PR is fairly small but it does change the fundamental flow of the requests that the provider makes to Azure API, it's worth a careful consideration. The goal is to minimize the diffs between `pulumi up` and `pulumi refresh`. ### Current situation We use PUT operations for both resource creation and updates. The provider's Create() and Update() methods call the PUT endpoint associated with a resources and awaits for HTTP response, that may come immediately of after the long-running operation (LRO) succeeds. Still, logically, it's a response from the PUT request, as it's defined in Open API specs and implemented in the actual API. We calculate resource outputs from that response. When we refresh (or import) resources, the provider's Read() method calls the GET (sometimes it's POST) endpoint of the same resource. It then calculates resource outputs and inputs from it. Open API (potentially) defines the type of GET response separately from PUT response. Our implicit assumption here is that actually PUT response and GET response have the same shape and the same data for the same resource. This assumption is mostly okay, but not perfect. As #2245 and #2798 report, and `RequireEmptyPreviewAfterRefresh=false` tests demonstrate, the actual payloads of PUT vs. GET may differ. In particular, I noticed the following scenario: 1. Some resource properties have default values that are assigned by Azure. 2. A user does not set any value for such property. 3. PUT response still has no default value. 4. GET response does return the default value. 5. Refresh finds the PUT vs GET discrepancy and updates state. 6. The next Update thinks those values were removed from the code, and suggests updating them. 7. Even though it's a no-op on Azure, it's a diff that the users sees and get confused. ### Proposed change This PR amends the flow of Create() and Update() by an extra GET call after successful PUT operation. The response of that extra GET is what is used to calculate resource outputs. This guarantees that the shapes and data of Create/Update outputs and Read outputs are going to be the same. It resolves the problematic flow above, as proved by test changes. The only downside that I can see is that we do an extra GET request for each resource change, which may slow things down. However, we observe that GET endpoints are much faster than PUTs, especially for LRO-based resources. I assert that the correctness win has exceedingly high values compared to this minor slowdown. Resolve #2798 Resolve #2245
- Loading branch information
1 parent
d71ffb8
commit 151c80b
Showing
8 changed files
with
80 additions
and
50 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters