From Joe Wysk: Sometimes it's convenient to create tf module resources (tf state) that are not just parameterized by MATURITY. For example, the TF state might be in a weird state and you want to try a deployment with an empty TF state, but leave the "bad" TF state untouched.

It tries to create state buckets with UC characters and fails! Also needs to be bumped in CIRRUS-DAAC: https://github.com/asfadmin/CIRRUS-DAAC/blob/master/jenkins/Jenkinsfile#L3

Allow the users to trace back the changes to the original authors of the source code.

Show the relationships between these two repos (and forks of CIRRUS-DAAC).

-p profile name
-m maturity
-d deploy name

Or something similar.

See if these can be simplified / minified in some way.

In one account the subnet returned was the correct one but in another account it was wrong (it was the subnet id of owned resources)

Issue: container-shell make stage fails in the current container specified in the Dockerfile.

This is failing as ssh-keygen is returning the following error:

No user exists for uid 502

Example:

bash-4.2:/CIRRUS-core$ source setup_jwt_cookie.sh some_daac jk dev
<removed echo-back for security reasons>
No user exists for uid 502

Replication steps:

1. make image
2. make container-shell, and run the specified command from the docs (setup_jwt_cookie.sh), or directly invoke the portion of the script that is failing

Look this up from the account by using a Terraform AWS data provider.

The make checkout-daac ... target is useful for CI/CD jobs, but for local development it would be nice to link directly to the directory of the DAAC repo.

When building a core docker image there is a script deprecation warning on the setup_14.x command below

=> [core_base 2/7] RUN         curl -sL https://rpm.nodesource.com/setup_14.x | bash - &&         curl -sL https://dl.yarnpkg.com/rpm/yarn.repo | tee /etc/yum.repos.d/yarn.repo &&         yum update  16.3s
 => => #   information both about supported versions of Node.js and supported Linux                                                                                                                           
 => => #   distributions. To learn more about usage, see the repository:                                                                                                                                      
 => => #     https://github.com/nodesource/distributions                                                                                                                                                      
 => => # ================================================================================                                                                                                                     
 => => # ================================================================================   

inside the docker container, the first time I run source env.sh aws_profile_name deploy maturity it uses my default aws profile rather than the one named in the call. This script was updated in PR #58 by @mckadesorensen . Could this be looked at? I see that $AWS_PROFILE is used 3 times prior to it being defined in line 12.

To: All tenants of the Earthdata Cloud
Subject: Addressing AWS managed deprecations (Lambda/RDS) as part of 23.4
What’s Happening:
AWS has announced the end of support for various lambda runtimes slated during 23.4 and aurora postgresql v11.x in January 2024. Please review and update these components as necessary. Lambda runtime deprecations have two stages; the first prevents the deployment of new lambdas with that runtime and the second prevents even the updating of lambdas with that runtime. On the RDS front, per AWS, they will automatically perform a major version update: "If you do not upgrade your database running Aurora PostgreSQL 11.x before January 31, 2024, Amazon Aurora will upgrade your Amazon Aurora PostgreSQL 11.x databases to the appropriate Amazon Aurora PostgreSQL major version during a scheduled maintenance window on or after January 31, 2024."

Lambda Runtime Phase 1 Deprecation Date
Node.js 14 11/27/23
Python 3.7 11/27/23
Ruby 2.7 12/7/23
Java 8 (AL1) 12/31/23
Go 1.x 12/31/23
Node.js 16 3/11/24

For information about Lambda runtime deprecations: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
For information about Postgresql end of support: https://repost.aws/questions/QUqTaY2mfcTSWoioVXmxSQdQ/announcement-amazon-aurora-postgresql-11-x-end-of-support-is-january-31-2024For support or questions, contact Earthdata Cloud Operations

If the project is configured in CircleCI, use it to at least validate the Terraform, and include a job that will deploy Cumulus.

From Abdelhak Marouane @ GHRC: He would like to be able to run a single script to both set the environment variables and deploy Cumulus.

Expose the Lambda ARNs and other resources that are needed in a CIRRUS-DAAC workflow Terraform configuration.

Like Jenkins and CircleCI, include a Bamboo configuration that validates the Terraform and deploys Cumulus. Specifically, this would likely be customized for the ECC Bamboo service.

Cumulus has a default value for the ecs_cluster_instance_image_id variable, but it's not a supported AMI. Probably this variable should not have a default and instead be required. So for now, in CIRRUS add an empty value for ecs_cluster_instance_image_id.

Currently the data-persistence/main.tf and the cumulus/main.tf have module source URLs which embed the Cumulus version in it. This is currently a limitation of the module source parameter, because it can't include variable substitution and must be a fixed string. Is there a better way to do this?

They default to DEV, but they should match MATURITY.

Remove the cumulus/secrets and the use of these in the Makefile. Instead, modify the Terraform to lookup secrets from the account's AWS Secrets Manager. Then include instructions for provisioning these secrets prior to deploying Cumulus.

The cumulus/main.tf looks up the VPC and Subnet IDs, but only uses the first subnet. I did this as a temporary fix of a problem with deploying using both subnet IDs. I don't actually remember what the issue was. So: see if it's still an issue if we use both subnets, and resolve it!

Add a target to create a Terraform plan. When running in CI/CD, should this be a build artifact that gets stored as the output of the job running. E.g., in CircleCI, I think we can take the build plan and store it as an artifact so that a user could review it.

https://github.com/nasa/cumulus/releases/tag/v1.18.0

The HelloWorldWorkflow is a good one.

Either all of them, or specific modules (tf, daac, data-persistence, cumulus).