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.

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

BB2-2910: BB2 Terraform Quicksight Analysis for PROD-APPS Dashboard #2151

Merged

Conversation

dtisza1
Copy link
Contributor

@dtisza1 dtisza1 commented Jan 19, 2024

JIRA Ticket:
BB2-2910

User Story or Bug Summary:

As a part of the BB2 BFD Insights terraforming epic, we aim to enhance our configuration management by Terraforming our QuickSight Analysis used for the PROD-APPLICATIONS dashboard. This will enable us to efficiently configure and version-control this analysis, ensuring seamless tracking of changes as code.

What Does This PR Do?

NOTES:

Sensitive values are stored in a shared terraform.tfvars file currently, but we are planning to refactor this to use AWS SSM as a future improvement task BB2-2498.

Determined that the UUID type identifiers for Analysis components are non-sensitive. These are for internal identifiers, like sheet_id, filter_id, visual_id, and others. For example, the same IDs can be used in both TEST and PROD versions/copies.

There are two workspaces setup:

  • test - For development and testing purposes.
  • prod - For production.

The prod workspace will be deployed after the full set of related Quicksight components are complete and reviewed together in test.

The following is a summary of work done for this PR:

  • Created a module for the Analysis:

    • quicksight-analysis-prod-applications
      • resource "aws_quicksight_analysis" "quicksight_analysis_prod_applications"
  • Utilized Terraform import & plan changes, and the AWS CLI (describe) outputs to create code for the resource definition in the module main.tf.

    • The original Analysis was created using the AWS Quicksight UI, so this original state was imported.
    • After import, the TF code for the DEFINITION was created by starting with a skeleton TF code, then using the terraform plan changes output to create the definition in main.tf.
      • Several TF import, plan and other issues were worked around to get working TF code.
        • See the following "What Should Reviewers Watch For" section for info about the remaining minor issue---that could not be resolved at this time.
    • So the definition TF code is quite large (approx. 4K lines).
      • Only the 1st 50 lines of main.tf are of main interest for review.
      • Of interest are the permissions and data_set_identifiers_declarations sections.
        • Note that the underlying datasets used are determined by the values in the terraform.tfvars and are different per test vs prod workspace.
        • One exception is the use of the first_app_name_select variable at line 619.
      • For the rest of the definition, see the notes related to the UUID identifiers.
        • A few passes were made reviewing the other 4K lines of definition code.

What Should Reviewers Watch For?

If you're reviewing this PR, please check for these things in particular:

A possible AWS provider bug (as of 5.29.0) was encountered and the terraform plan is always showing some changes. However, the resulting Analysis is working OK after a terraform apply.

For example, there are several of these types of changes shown for the definition:

  ~ row_header_style {
      ~ height                    = 0 -> 40
      + text_wrap                 = "WRAP"
  }

For the above, the height value is 0 in the Analysis; however, setting this in the TF code produces an error with a message that the value must be greater than 0. Also, the value is never changed to 40 after an apply. This had worked for setting other height values, but does not work for row_header_style. Hopeful that a future AWS provider version will handle this case, and we can get a clean "No changes" result for the apply.

What seem to be other provider bugs related to import, plan and apply were able to be worked around, by making changes to the TF code and the Analysis via the Quicksight UI.

What Security Implications Does This PR Have?

Submitters should complete the following questionnaire:

  • If the answer to any of the questions below is Yes, then you must supply a link to the associated Security Impact Assessment (SIA), security checklist, or other similar document in Confluence here: N/A

    • Does this PR add any new software dependencies?
      • Yes
      • No
    • Does this PR modify or invalidate any of our security controls?
      • Yes
      • No
    • Does this PR store or transmit data that was not stored or transmitted before?
      • Yes
      • No
  • If the answer to any of the questions below is Yes, then please add @StewGoin as a reviewer, and note that this PR should not be merged unless/until he also approves it.

    • Do you think this PR requires additional review of its security implications for other reasons?
      • Yes
      • No

What Needs to Be Merged and Deployed Before this PR?

Submitter Checklist

I have gone through and verified that...:

  • I have named this PR and branch so they are automatically linked to the (most) relevant Jira issue. Ie: BFD-123: Adds foo
  • This PR is reasonably limited in scope, to help ensure that:
    1. It doesn't unnecessarily tie a bunch of disparate features, fixes, refactorings, etc. together.
    2. There isn't too much of a burden on reviewers.
    3. Any problems it causes have a small "blast radius".
    4. It'll be easier to rollback if that becomes necessary.
  • This PR includes any required documentation changes, including README updates and changelog / release notes entries.
  • The data dictionary has been updated with any field mapping changes, if any were made.
  • All new and modified code is appropriately commented, such that the what and why of its design would be reasonably clear to engineers, preferably ones unfamiliar with the project.
  • All tech debt and/or shortcomings introduced by this PR are detailed in TODO and/or FIXME comments, which include a JIRA ticket ID for any items that require urgent attention.
  • Reviews are requested from both:
    • At least two other engineers on this project, at least one of whom is a senior engineer or owns the relevant component(s) here.
    • Any relevant engineers on other projects (e.g. DC GEO, BB2, etc.).
  • Any deviations from the other policies in the DASG Engineering Standards are specifically called out in this PR, above.
    • Please review the standards every few months to ensure you're familiar with them.

@dtisza1 dtisza1 requested a review from meliGuzman January 22, 2024 19:41
Copy link
Member

@mjburling mjburling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another step in a positive direction. Thanks!

@dtisza1 dtisza1 merged commit e76b610 into master Jan 25, 2024
10 checks passed
@dtisza1 dtisza1 deleted the dtisza1/BB2-2910-terraform-quicksight-analysis-prod-apps branch January 25, 2024 15:53
mackec1 pushed a commit that referenced this pull request Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants