#pr-reviews (2020-07)
Pull Request Reviews for Cloud Posse Projects
2020-07-07

Can someone take a look at my (small) PR? https://github.com/cloudposse/terraform-aws-ses/pull/5 Thanks!
what Adds a user_secret output which contains the IAM Secret why This allows that the IAM User can (also) be used through the SES API and not just via SMTP references

@Marcin Brański
what Adds a user_secret output which contains the IAM Secret why This allows that the IAM User can (also) be used through the SES API and not just via SMTP references

Thanks Frank. I have reviewed and released already your changes https://github.com/cloudposse/terraform-aws-ses/releases/tag/0.3.0
Thanks to @syphernl for work on this PR! what Adds a user_secret output which contains the IAM Secret why This allows that the IAM User can (also) be used through the SES API and not just via SMTP


One thng…


I see we are missing this in our “Best Practices”, so updating that now. https://docs.cloudposse.com/terraform/terraform-best-practices/

Yeah, didn’t know that.

I’m adding it to the backlog
2020-07-08
2020-07-14

I noticed that https://github.com/cloudposse/terraform-aws-ecr will only keep the latest 500 images around (the number being configurable). I opened https://github.com/cloudposse/terraform-aws-ecr/pull/56 to allow protecting specific tags like prod
, but am curious:
How does cloudposse expect that the repo would be used. In continuous delivery (but not continuous deployment) environments, how could you be sure that the image you are using in production won’t be deleted before your next release starts?
Terraform Module to manage Docker Container Registries on AWS ECR - cloudposse/terraform-aws-ecr
what Allow protecting images with a given set of tag names why At Transcend, we tag images with dev, staging, and prod for deployments in addition to their SHA tags. We want to expire images, bu…

Well in continuos delivery situations you will be deploying all the time so it will be hard to believe you will need to deploy anything older than the last release? Most of what I have seen is that you roll forward not backwards
Terraform Module to manage Docker Container Registries on AWS ECR - cloudposse/terraform-aws-ecr
what Allow protecting images with a given set of tag names why At Transcend, we tag images with dev, staging, and prod for deployments in addition to their SHA tags. We want to expire images, bu…

In prod that is

If you have to roll back 200 releases then your whole pipeline has a very bad testing process

You could have 3 ecr repos for each stage/environment

My understanding is that continuous deployment = deploying all the time, continuous delivery = ready to deploy all the time.
So in continuous delivery, you will not deploy on every build.
We push up docker images to run e2e tests on on every commit, and it’s not terribly uncommon for us to have 500+ commits pushed in a week (which is how often we deploy to prod)

We have a single ECR repo in a “Commons” AWS account that our dev/staging/prod accounts all share in common. This way we can just promote any image to have the dev tag, then later promote that same image to staging, then prod.
So there can be quite a few images that get added, as it’s not a repo just for prod images

we do something similar but we do not deploy as much at all

I’m reviewing your pr

new release tagged, thanks for the pr