-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
fix resourceDashboardUpdate #34227
fix resourceDashboardUpdate #34227
Conversation
Community NoteVoting for Prioritization
For Submitters
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Welcome @dsbibby 👋
It looks like this is your first Pull Request submission to the Terraform AWS Provider! If you haven’t already done so please make sure you have checked out our CONTRIBUTOR guide and FAQ to make sure your contribution is adhering to best practice and has all the necessary elements in place for a successful approval.
Also take a look at our FAQ which details how we prioritize Pull Requests for inclusion.
Thanks again, and welcome to the community! 😃
749b261
to
4ae51ba
Compare
Hi, how do I encourage a review of this PR please? It's a pretty minor change to address a nasty bug that is stopping us (and surely others) from using this. |
@@ -203,7 +203,7 @@ func resourceDashboardRead(ctx context.Context, d *schema.ResourceData, meta int | |||
return diag.FromErr(err) | |||
} | |||
|
|||
out, err := FindDashboardByID(ctx, conn, d.Id()) | |||
out, err := FindDashboardByID(ctx, conn, d.Id(), -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we always want the latest version as this is hardcoded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue this MR tries to fix is urgent since the current provider version makes it impossible to update a dashboard.
To update a dashboard we currently use the workaround to rename the dashboard, hence deleting the old and creating a new dashboard. This has the impact of making the user data, such as bookmarks, customisation, etc, vanish for the user and therefore not making it very user-friendly.
@dev-slatto I struggle to understand the concern you are raising. The old version of the code also tries to update to the latest version and it does not even allow you to update the dashboard at all since it now throws the error referred to in this MR.
When deploying a new version it would be (in my opinion) natural to deploy the latest version in most of the use cases. I struggle to see a good use case for not enabling the latest version except for maybe testing the new version before it is published to everyone. We have separate dev/test/prod env, so for us, it makes sense to always publish the latest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we always want the latest version as this is hardcoded?
That is the current (as in before this PR) behaviour, so no change to the current behaviour.
That said, we could easily add a version parameter to this resourceDashboardRead()
function if that would be beneficial for the future?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a chat with Graham and we concluded that it makes sence for a hardcoded version for the resource, and that a data source of dashboard should be able to include the version parameter. However, see the comment later down in the PR about defining the version as a constant instead of hardcoding it 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, I have updated to use a constant 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR, @dsbibby. It looks good, though I have a few suggestions
@@ -367,15 +368,26 @@ func resourceDashboardDelete(ctx context.Context, d *schema.ResourceData, meta i | |||
return nil | |||
} | |||
|
|||
func FindDashboardByID(ctx context.Context, conn *quicksight.QuickSight, id string) (*quicksight.Dashboard, error) { | |||
// Pass version as -1 for latest published version, or specify a specific version if required |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should define a constant, e.g. dashboardLatestVersion
instead of using -1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done!
var descOpts *quicksight.DescribeDashboardInput | ||
|
||
if version == -1 { | ||
descOpts = &quicksight.DescribeDashboardInput{ | ||
AwsAccountId: aws.String(awsAccountId), | ||
DashboardId: aws.String(dashboardId), | ||
} | ||
} else { | ||
descOpts = &quicksight.DescribeDashboardInput{ | ||
AwsAccountId: aws.String(awsAccountId), | ||
DashboardId: aws.String(dashboardId), | ||
VersionNumber: &version, | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be more clear to understand to have something like
var descOpts *quicksight.DescribeDashboardInput | |
if version == -1 { | |
descOpts = &quicksight.DescribeDashboardInput{ | |
AwsAccountId: aws.String(awsAccountId), | |
DashboardId: aws.String(dashboardId), | |
} | |
} else { | |
descOpts = &quicksight.DescribeDashboardInput{ | |
AwsAccountId: aws.String(awsAccountId), | |
DashboardId: aws.String(dashboardId), | |
VersionNumber: &version, | |
} | |
} | |
descOpts := &quicksight.DescribeDashboardInput{ | |
AwsAccountId: aws.String(awsAccountId), | |
DashboardId: aws.String(dashboardId), | |
} | |
if version != dashboardLatestVersion { | |
descOpts.VersionNumber = aws.Int64(version) | |
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's neater, done 👍
@@ -297,14 +297,15 @@ func resourceDashboardUpdate(ctx context.Context, d *schema.ResourceData, meta i | |||
return create.DiagError(names.QuickSight, create.ErrActionUpdating, ResNameDashboard, d.Id(), err) | |||
} | |||
|
|||
if _, err := waitDashboardUpdated(ctx, conn, d.Id(), d.Timeout(schema.TimeoutUpdate)); err != nil { | |||
updatedVersionNumber := extractVersionFromARN(aws.StringValue(out.VersionArn)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because of how extractVersionFromARN
is used here, it should return int64
instead of *int64
. That way, the parameter will not need to be dereferenced when passed to waitDashboardUpdated
. When setting the parameter on publishVersion
, use aws.Int64(updatedVersionNumber)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have addressed this 👍
testAccCheckDashboardVersionExists(ctx, resourceName, 1, &dashboard), | ||
testAccCheckDashboardName(&dashboard, rName), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For clarity, these should indicate that they're referencing version 1, e.g.
testAccCheckDashboardVersionExists(ctx, resourceName, 1, &dashboard), | |
testAccCheckDashboardName(&dashboard, rName), | |
testAccCheckDashboardVersionExists(ctx, resourceName, 1, &dashboardV1), | |
testAccCheckDashboardName(&dashboardV1, rName), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to dashboardV1
I have addressed the comments so far. In testing this with a massive config I have access to, I got blocked by a couple of minor typos for which there are existing issues and a regression introduced by #33931 - I added fixes for these also so that I could complete my tests. Hope that is OK. |
2d8cacc
to
061a321
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! 🚀
--- PASS: TestAccQuickSightDashboard_disappears (31.92s)
--- PASS: TestAccQuickSightDashboard_dashboardSpecificConfig (32.84s)
--- PASS: TestAccQuickSightDashboard_sourceEntity (35.41s)
--- PASS: TestAccQuickSightDashboard_basic (35.93s)
--- PASS: TestAccQuickSightDashboard_updateVersionNumber (57.83s)
This functionality has been released in v5.43.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Description
This PR addresses a bug in the aws_quicksight_dashboard resource.
When terraform updates a dashboard resource, two AWS API calls are made. The first updates the dashboard which results in a new dashboard version. The second call should update the published version of the dashboard to the new version.
The bug manifests when the first call takes a little time, which results in the second call returning an error about the dashboard creation still being in progress.
This is because the provider waits for the dashboard status to change to creation successful, however the API call used is checking the current published version, not the new version just made. As such it returns early and doesn’t actually wait.
This PR fixes this by explicitly waiting for the new version of the dashboard to be created before trying to update the published version.
Additionally this PR fixes two minor typo issues, and an issue caused when the state file for a template contains an empty string, resulting in "Error: a number is required" errors.
Relations
Closes #33463
Closes #35109
References
Redacted screenshot showing the failure:
Output from Acceptance Testing