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

Updates made on NSIDC Fork #193

Merged
merged 9 commits into from
Jun 17, 2024
Merged

Updates made on NSIDC Fork #193

merged 9 commits into from
Jun 17, 2024

Conversation

mikedorfman
Copy link
Collaborator

@mikedorfman mikedorfman commented May 29, 2024

We're working to get from our fork back to the asfadmin/CIRRUS-core baseline. These are a few of the smaller changes we had made on our fork. These changes should not result in changed default behavior. The changes include:

  • Adding urs_tea_client_id and urs_tea_client_password to specify alternative client id and password for use in TEA. If not specified, this defaults to urs_client_password/id variables.
  • Adding optional ecs_include_docker_cleanup_cronjob, which defaults to False
  • Fixing the value of report_granules_sns_topic_arn, updating it from module.cumulus.report_executions_sns_topic_arn to module.cumulus.report_granules_sns_topic_arn.
  • Adding {DAR = "YES"} to the list of tags passed into TEA for use in the buckets created by this module
  • Updated TEA bucket map so we do not redeploy the bucket map file if the file name is specified.

@mikedorfman mikedorfman changed the title Several changes Updates made on NSIDC Fork May 29, 2024
Copy link
Collaborator

@lindsleycj lindsleycj left a comment

Choose a reason for hiding this comment

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

Other than the DAR question, I'm fine with this PR

@@ -23,7 +23,7 @@ module "thin_egress_app" {
urs_auth_creds_secret_name = aws_secretsmanager_secret.thin_egress_urs_creds.name
use_cors = var.use_cors
vpc_subnet_ids = data.aws_subnets.subnet_ids.ids
tags = local.default_tags
tags = merge(local.default_tags, {DAR = "YES"})
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does TEA create a bucket? I'm not sure why this is needed.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, the TEA terraform module creates a bucket for the lambda source code zip, dependency layer zip, and CloudFormation.

We are in the process of releasing a new version of TEA that adds the DAR tag to the bucket: https://github.com/asfadmin/thin-egress-app/releases/tag/tea-release.2.0.1

I think it would be better to update the version of TEA rather than pass the tags in like this, because doing it this way will also tag the CloudFormation stack with the DAR tag meaning it will tag every resource (lambdas, queues, API gateways, etc) with the DAR tag.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good to know - agreed, it is better to update in TEA than to include this tag with everything in the TEA stack. I'll remove this from the PR given that this work is ongoing.

Copy link
Contributor

@reweeden reweeden left a comment

Choose a reason for hiding this comment

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

Most of it looks good, I just don't understand why we might need 2 different URS clients.

@@ -116,7 +116,7 @@ output "report_executions_sns_topic_arn" {
value = module.cumulus.report_executions_sns_topic_arn
}
output "report_granules_sns_topic_arn" {
value = module.cumulus.report_executions_sns_topic_arn
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice

Copy link
Contributor

Choose a reason for hiding this comment

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

Great catch!

Comment on lines 155 to 164
variable "urs_tea_client_id" {
type = string
default = null
}

variable "urs_tea_client_password" {
type = string
default = null
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we move these down to where the other TEA variables are?

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe add a description saying that they will default to the non-tea version of the variables?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good call - done in the next commit.

Comment on lines 155 to 163
variable "urs_tea_client_id" {
type = string
default = null
}

variable "urs_tea_client_password" {
type = string
default = null
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you explain to me the use case for having different URS clients for TEA and cumulus?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good question! This update predates my time at NSIDC, but I believe this is because the dashboard (corresponding to the urs_client_id/password) and the TEA (corresponding to the urs_tea_client_id/password) are two separate EDL applications that have different IDs and passwords.

})
}

resource "aws_s3_object" "bucket_map_yaml" {
# If bucket_map_key is set, we already have a bucket map on S3 and don't need to create one
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe clarify that it's coming from the daac module instead something like this:

Suggested change
# If bucket_map_key is set, we already have a bucket map on S3 and don't need to create one
# If bucket_map_key is set, the daac module already created one and we can skip creation here

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Good call - updated on the next commit.

})
}

resource "aws_s3_object" "bucket_map_yaml" {
# If bucket_map_key is set, we already have a bucket map on S3 and don't need to create one
count = local.bucket_map_key == null ? 1 : 0
Copy link
Contributor

Choose a reason for hiding this comment

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

At ASF we just changed the key that the daac module uploads the bucket map to so that it doesn't conflict with the core bucket map and then we just ignore the core bucket map. But it's probably less confusing for core to just skip creating that extraneous bucket map all together.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I see - this makes sense and is good to know!

mikedorfman and others added 2 commits May 31, 2024 12:27
@mikedorfman mikedorfman merged commit 832167e into master Jun 17, 2024
2 checks passed
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.

5 participants