-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
Step generator panics #2223
Comments
I just hit this earlier as well. The root cause of this issue is that an input to a first-class provider changed, and the new value was not known at preview time. When a first-class provider has any unknown configuration values, we do not configure its underlying plugin. We do this in order to avoid unexpected behavior, as no provider plugin is currently able to handle unknown configuration values (there are plans to fix this; see #1718). Prior to #2088, we would never attempt to use an unconfigured provider. Before those changes, any unknown input to a provider would cause the provider to require replacement during preview. This would cascade s.t. all of the resources managed by the provider also required replacement, which does not require a call to Any fix here is fraught with user experience issues. We cannot call the underlying provider--it is not configured, and we cannot configure it--so whatever we return from The long-term fix for this is to implement the changes in #1718. |
Given that this causes a panic, it seems that it's net worse than prior to #2088, and that we will need to get some fix in place to avoid the panic and turn this back into a "preview UX" issue". |
@lukehoban what did you think of this approach?
|
That proposal sounds okay to me, especially if we can add a "warn" message to the status to indicate that there is an unknown input and we can't be sure whether replacement will be required. How likely are we to be able to properly fix this via #1718 in M20? |
We can prioritize that work if we believe that it is necessary. It's a pretty simple set of changes, so I doubt that it will take very long to implement the core pieces. The trickier work is in the various providers that want to support partial configuration. We will probably want to improve the "diff is uncertain" UX when addressing that as-well, maybe going so far as to make it a first-class scenario. |
After #2088, we began calling `Diff` on providers that are not configured due to unknown configuration values. This hit an assertion intended to detect exactly this scenario, which was previously unexpected. These changes adjust `Diff` to indicate that a Diff is unavailable and return an error message that describes why. The step generator then interprets the diff as indicating a normal update and issues the error message to the diagnostic stream. Fixes #2223.
After #2088, we began calling `Diff` on providers that are not configured due to unknown configuration values. This hit an assertion intended to detect exactly this scenario, which was previously unexpected. These changes adjust `Diff` to indicate that a Diff is unavailable and return an error message that describes why. The step generator then interprets the diff as indicating a normal update and issues the error message to the diagnostic stream. Fixes #2223.
This happens when I updated the username of a GKE cluster.
cc @swgillespie @pgavlin @lukehoban
The text was updated successfully, but these errors were encountered: