-
-
Notifications
You must be signed in to change notification settings - Fork 22
add dev cloudcasting api module and vars #895
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
base: main
Are you sure you want to change the base?
Conversation
type = string | ||
default = "not-set" | ||
} | ||
variable "s3_secret_access_key" { |
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.
you wont need these things, it will use what IAM role and permission from that
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.
Yeah I was just trying to get deployed with minimal changes to the code for now, this will be better going forward, but is obv different to how Suvan has had to set it up
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.
Yea i see. I would probably still remove them here, and adjust Suvans code a tiny bit. In general the less credientials and secruty things we can do, the better.
Ill leave it up to you on that.
if you do keep this in, please make sure the access key and id are tightly locked down, and only have access to relevant things
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.
If the code uses boto3 it should fallback to the default connection strategy. I think EB might even set these variables in the environment by default so you might not even need to make any code changes at all - not that I've looked at the code.
{ "name" : "ENVIRONMENT", "value" : local.environment }, | ||
{ "name" : "S3_BUCKET_NAME", "value" : var.s3_cloudcasting_bucket_name }, | ||
{ "name" : "S3_REGION_NAME", "value" : var.s3_cloudcasting_region_name }, | ||
{ "name" : "S3_ACCESS_KEY_ID", "value" : var.s3_access_key_id }, |
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.
as below, you can remove S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY.
There's a small chance we will have to change the code accordindly
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.
Might need to add the
s3_bucket = [{ bucket_read_policy_arn = module.s3.iam-policy-s3-sat-read.arn }]
when replacing these too.
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 great, just some small changes, but then it should be all good
{ "name" : "AUTH0_DOMAIN", "value" : var.auth_domain }, | ||
{ "name" : "AUTH0_API_AUDIENCE", "value" : var.auth_api_audience }, | ||
{ "name" : "AUTH0_CLIENT_ID", "value" : var.auth_dashboard_client_id }, | ||
{ "name" : "ENVIRONMENT", "value" : local.environment }, |
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.
Does the app use any of these variables? If not, I'd remove them from here altogether.
] | ||
container-name = "cloudcasting_api" | ||
container-tag = var.api_version | ||
container-registry = "openclimatefix" |
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.
Just worth checking, this will only work if the container is deployed to docker hub. I suspect it's only being deployed to GHCR, so this will in fact want to be ghcr.io/openclimatefix
. In fact, most of these probably want to be changed to that, but that's another task for another day!
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.
Although from what you're saying it sounds like there isn't a build CI, so maybe it is being manually pushed to docker hub - but in that case I wouldn't expect it to be under the openclimatefix
org...
{ "name" : "S3_BUCKET_NAME", "value" : var.s3_cloudcasting_bucket_name }, | ||
{ "name" : "S3_REGION_NAME", "value" : var.s3_cloudcasting_region_name }, |
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.
[1] These don't need to be variables - since they're accessing the sat bucket, we can use the output from the s3 module that creates the bucket:
{ "name" : "S3_BUCKET_NAME", "value" : module.s3.s3-sat-bucket.id }
{ "name" : "S3_REGION_NAME", "value" : var.region }
variable "s3_cloudcasting_bucket_name" { | ||
description = "The name of the S3 bucket to use for storing data" | ||
type = string | ||
default = "not-set" | ||
} | ||
|
||
variable "s3_cloudcasting_region_name" { | ||
description = "The region of the S3 bucket to use for storing data" | ||
type = string | ||
default = "not-set" | ||
} |
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.
These can be removed as per [1]
type = string | ||
default = "not-set" | ||
} | ||
variable "s3_secret_access_key" { |
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.
If the code uses boto3 it should fallback to the default connection strategy. I think EB might even set these variables in the environment by default so you might not even need to make any code changes at all - not that I've looked at the code.
{ "name" : "ENVIRONMENT", "value" : local.environment }, | ||
{ "name" : "S3_BUCKET_NAME", "value" : var.s3_cloudcasting_bucket_name }, | ||
{ "name" : "S3_REGION_NAME", "value" : var.s3_cloudcasting_region_name }, | ||
{ "name" : "S3_ACCESS_KEY_ID", "value" : var.s3_access_key_id }, |
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.
Might need to add the
s3_bucket = [{ bucket_read_policy_arn = module.s3.iam-policy-s3-sat-read.arn }]
when replacing these too.
{ "name" : "S3_DOWNLOAD_INTERVAL", "value" : var.s3_download_interval }, | ||
{ "name" : "RELOAD", "value" : var.cloudcasting_reload}, |
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.
[2] Do you see these changing often? If not, they might be alright hard coded in the module declaration here, instead of being a variable. Using a var isn't necessarily wrong, but it's just one fewer transient to keep track of. If we do keep them as vars, I'd prefix the s3_download_interval
with cloudcasting
as well, just so it's clear what it pertains to in the terraform app - it's a bit vague as-is.
variable "s3_download_interval" { | ||
description = "The interval in seconds at which to download data from the S3 bucket" | ||
type = number | ||
default = 30 | ||
} |
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.
Maybe can be removed as per [2]
variable "cloudcasting_reload" { | ||
type = bool | ||
default = true | ||
} |
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.
Maybe can be removed as per [2]
{ "name" : "RELOAD", "value" : var.cloudcasting_reload}, | ||
] | ||
container-name = "cloudcasting_api" | ||
container-tag = var.api_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.
This means it will use the same tag as the (Quartz)API - which I'm assuming isn't what you want? Unless the packaging version of this app is synced to the (Quartz)API?
I hope this is ok @braddf , i changed this to a draft, as I understood you have currently deploy this a different way |
Pull Request
Description
Adding terraform module for new Cloudcasting API deploy.
Checklist: