Add Astro Scenario Examples

[ichung08]

Description

We want to replicate the standard 3 Astro scenarios in terraform as examples users can reference and run.

Scenarios:

Workspace Per Environment

• Dev workspace
  • Team 1 Dev Deployment
  • Team 2 Dev Deployment
  • Team 3 Dev Deployment
• Staging Workspace
  • Team 1 Staging Deployment
  • Team 2 Staging Deployment
  • Team 3 Staging Deployment
• Prod Workspace
  • Team 1 Prod Deployment
  • Team 2 Prod Deployment
  • Team 3 Prod Deployment

Workspace Per Team

• Team 1 Workspace
  • Dev Deployment
  • Stage Deployment
  • Prod Deployment
• Team 2
  • Dev Deployment
  • Stage Deployment
  • Prod Deployment
• Team 3
  • Dev Deployment
  • Stage Deployment
  • Prod Deployment

Workspace Per Team and Per Environment

• Team 1 workspace non-prod
  • Team 1 dev deployment
  • Team 1 staging deployment
• Team 1 workspace prod
  • Team 1 prod deployment
• Team 2 workspace non-prod
  • Team 2 dev deployment
  • Team 2 staging deployment
• Team 2 workspace prod
  • Team 2 prod deployment
• Team 3 workspace non-prod
  • Team 3 dev deployment
  • Team 3 staging deployment
• Team 3 workspace prod
  • Team 3 prod deployment

🎟 Issue(s)

#36

🧪 Functional Testing

📸 Screenshots

workspace_per_environment:

workspace_per_team:

workspace_per_team_per_environment:

📋 Checklist

• Rebased from the main (or release if patching) branch (before testing)
• Added/updated applicable tests
• Added/updated examples in the examples/ directory
• Tested against Astro-API
• Communicated to/tagged owners of respective clients potentially impacted by these changes.
• Updated any related documentation

[ichung08]

Testing Observations:

• Cannot create dedicated deployments using cluster_id = astro_cluster.prod_aws_cluster.id - seems like the deployment is waiting for the cluster id but doesn't get the id in time to create the deployment (since cluster takes a long time to create)
  • To create a dedicated deployment, you have to wait till cluster is created and then update the deployment's cluster_id to the new cluster's id - meaning you will have to run terraform apply multiple times
• Running terraform apply in main.tf with an existing cluster name causes an error. Why doesn't terraform treat this like other resources (eg. workspaces or deployments) and just update them?

│ Error: Client error
│ 
│   with astro_cluster.prod_aws_cluster,
│   on main.tf line 254, in resource "astro_cluster" "prod_aws_cluster":
│  254: resource "astro_cluster" "prod_aws_cluster" {
│ 
│ cluster name prod-aws-cluster already exists, status: 400, requestId: 627578ee-b3ac-4bc5-98de-8c3a9269d3f2

• Creating multiple clusters in main.tf only creates the first one, the other clusters fail
  
  • Running terraform apply doesn't fix failed clusters - shouldn't it retry them if they fail?

[kushalmalani]

@ichung08 Can we add a note on each of those scenarios to describe what exactly it is?

[kushalmalani]

Also, do we want to add dev and staging scenarios in that doc?

[ichung08]

Also, do we want to add dev and staging scenarios in that doc?

What do you mean by this? The scenarios cover a combination of dev, staging and prod in each scenario.

[kushalmalani]

Also, do we want to add dev and staging scenarios in that doc?

What do you mean by this? The scenarios cover a combination of dev, staging and prod in each scenario.

I meant, the dev and staging scenario has no value add for customers. Considering this repo is going to be public, do we need those scenarios?

[ichung08]

Also, do we want to add dev and staging scenarios in that doc?

What do you mean by this? The scenarios cover a combination of dev, staging and prod in each scenario.

I meant, the dev and staging scenario has no value add for customers. Considering this repo is going to be public, do we need those scenarios?

Ah I see what you mean. I think as examples those scenarios can still be good to include (maybe change the names) as they show a different use case. Dev and Stage are setup to use standard deployments and Prod is setup for dedicated deployments.

[kushalmalani]

Also, do we want to add dev and staging scenarios in that doc?

What do you mean by this? The scenarios cover a combination of dev, staging and prod in each scenario.

I meant, the dev and staging scenario has no value add for customers. Considering this repo is going to be public, do we need those scenarios?

Ah I see what you mean. I think as examples those scenarios can still be good to include (maybe change the names) as they show a different use case. Dev and Stage are setup to use standard deployments and Prod is setup for dedicated deployments.

Yeah, that is what confused me...

[ichung08]

Also, do we want to add dev and staging scenarios in that doc?

What do you mean by this? The scenarios cover a combination of dev, staging and prod in each scenario.

I meant, the dev and staging scenario has no value add for customers. Considering this repo is going to be public, do we need those scenarios?

Ah I see what you mean. I think as examples those scenarios can still be good to include (maybe change the names) as they show a different use case. Dev and Stage are setup to use standard deployments and Prod is setup for dedicated deployments.

Yeah, that is what confused me...

Yea this was part of the requirements listed here: #36

[vandyliu]

will need to add astro_runtime_version to all the deployments as well

[ichung08]

astro_runtime_version is a read only attribute so we can't add it