#terraform-aws-modules (2022-03)

terraform Terraform Modules

Discussions related to https://github.com/terraform-aws-modules

Archive: https://archive.sweetops.com/terraform-aws-modules/

2022-03-15

kris avatar

Is there any open source module for RDS password rotation?

I can only find https://github.com/jessiehernandez/terraform-aws-database-credentials-rotator

jessiehernandez/terraform-aws-database-credentials-rotator

Module that creates an AWS Lambda function that is able to rotate database credentials.

jose.amengual avatar
jose.amengual

I remember I started working on a module for this and I never finished

jessiehernandez/terraform-aws-database-credentials-rotator

Module that creates an AWS Lambda function that is able to rotate database credentials.

jose.amengual avatar
jose.amengual

there is a lambda that is required and such

kris avatar

yeah, it seems need some quite effort to implement this .. It would be awesome if AWS can provide this functionality out of the box

1
this1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Ya, I don’t think so

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

cc @matt

2022-03-16

matt avatar
matt
06:12:03 PM

@matt has joined the channel

2022-03-19

Matthew Rose avatar
Matthew Rose

hey is there anything I can do to help https://github.com/cloudposse/terraform-aws-ecr/pull/88 get merged? quite keen to use it

what

• With the introduction of cross-account ECR for lambda functions, I have put together the necessary code to allow for this functionality

why

• Cross-account ECR is a feature many would use as it doesn’t require you to duplicate your ECR repositories in the same account where the lambda function resides saving money

references

https://aws.amazon.com/blogs/compute/introducing-cross-account-amazon-ecr-access-for-aws-lambda/

1
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

@matt

what

• With the introduction of cross-account ECR for lambda functions, I have put together the necessary code to allow for this functionality

why

• Cross-account ECR is a feature many would use as it doesn’t require you to duplicate your ECR repositories in the same account where the lambda function resides saving money

references

https://aws.amazon.com/blogs/compute/introducing-cross-account-amazon-ecr-access-for-aws-lambda/

2022-03-20

2022-03-21

Brent Garber avatar
Brent Garber

There any module that can automagically split rules into multiple SGs if you have more than 60?

RB (Ronak) (Cloud Posse) avatar
RB (Ronak) (Cloud Posse)

i don’t believe so

RB (Ronak) (Cloud Posse) avatar
RB (Ronak) (Cloud Posse)

what’s the need for so many different security group rules?

2022-03-24

ekristen avatar
ekristen

Who here can I talk to about cloud posse modules and their semver release structure? I’ve noticed some concerning trends (2 or 3 modules so far), (ie releasing patches with breaking changes)

Yonatan Koren (Codefresh) avatar
Yonatan Koren (Codefresh)

@Jeremy G (Cloud Posse) @Erik Osterman (Cloud Posse) are the best to talk to.

We aim very hard to not make any breaking changes for patch releases. However we use release drafter and sometimes contributors and even cloud Posse engineers forget to apply the correct labels.

Which modules in particular?

Jeremy G (Cloud Posse) avatar
Jeremy G (Cloud Posse)

@ekristen We are using major version zero which is treated specially in SemVer, to mean “anything may change at any time”. Nevertheless, we try hard to avoid making breaking changes at any time, and when we do make breaking changes, we label the release as such and provide migration details. It is never our intention to release a breaking change in a patch release; we intend breaking changes to be a minor release bump while we are still operating under major version zero. However, we do rely heavily on volunteers to maintain the modules and sometimes mistakes are made. Please give us details so we can address them.

A number of modules have breaking changes not due to anything Cloud Posse did, but due to breaking changes in the AWS Terraform provider version 4.0 which was recently released. There’s nothing we can do about that: previously working code stopped working if you upgraded to the latest provider. However, we did take the opportunity of being forced to make breaking changes to introduce additional breaking changes as we refactor our S3 implementations. Previously we had several modules which each had their own implementation of creating S3 buckets; we are migrating all our modules to instead use our terraform-aws-s3-bucket module for all S3 bucket operations so that we can provide consistent and full support of S3 in a manageable fashion.

For several months we have been working on doing the same kind of thing with AWS Security Groups, going from every module having their own implementation to every module delegating to terraform-aws-security-group. Unfortunately, our first attempt at this (security-group v0.3.x) went badly, and we are still in the process of rolling it back and upgrading to the current (v0.4.x) security-group module. We have fixed some of the modules, but not all of them. These modules with security-group v0.3.x in the main branch are in the worst state, in that any updates to them are breaking changes that we do not want people to adapt to because there will be more and different breaking changes when we finally get to v0.4.x. We have tried to prevent volunteers from doing this, but sometimes it happens anyway, for which all we have left is to apologize.

Semantic Versioning 2.0.0

Semantic Versioning spec and website

ekristen avatar
ekristen

Hey thanks for the reply! I want to be clear that I’m very thankful for what you’ve all done and not trying to suggest anything has been done or missed in malice. I tried raising and issue in the s3 bucket module for example 3 weeks ago with no response.

ekristen avatar
ekristen

I’m familiar with the 0 indicator for semver but not all your modules use that some are in 1.

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

I really wish CloudPosse modules would all bump to 1.0. The lack of semver is really annoying when upgrading. I have to carefully read each release’s changelog and try to determine if a change is backwards-compatible myself. For instance, this changelog (picking on myself): v0.29.0

Only specify ttl block if ttl_enabled is true @alexjurkiewicz (#95)
Is this backwards-compatible from 0.28.0? Who knows! I have to either read the PR’s diff or upgrade and check the plan.

ekristen avatar
ekristen

Thanks for that. I would then ask what is the criteria for stability? For example I’ve been using the s3 bucket for well over a year with zero issues but it’s not 1.x

ekristen avatar
ekristen

Happy to contribute or help in any way I can too.

ekristen avatar
ekristen

Thanks for the feedback and discussion

ekristen avatar
ekristen

Hey @Erik Osterman (Cloud Posse) why not just rev everything to 1.x? I mean I get the purpose of 0.x but if the api changes you are just going to rev the major anyways? Perhaps after initial development of a period of time just automatically go to 1.x and if the api changes rev the major. It might mean a few modules get into the 3-6.x range but then at least expectations of semver are there?

ekristen avatar
ekristen

Whoops didn’t mean to send that last to channel. Must have accidentally checked the box,

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

It’s more about our “contract” with anyone depending on our modules. We wanted to be transparent that the inferfaces could change and that we wouldn’t be managing older versions. They changed a lot. Keep in mind that we’ve been at this since pre 0.10. Now everything is more mature. Now we need to mature our management of it. It’s part technical and part managerial. I think we will get there this year.

1
Jeremy G (Cloud Posse) avatar
Jeremy G (Cloud Posse)

@ekristen wrote:
I’m familiar with the 0 indicator for semver but not all your modules use that some are in 1.
Which modules are you referring to?

ekristen avatar
ekristen

I was mistaken @Jeremy G (Cloud Posse)

2022-03-25

2022-03-27

Alex Jurkiewicz avatar
Alex Jurkiewicz

I have three PRs open here, if anyone is free to look at them https://github.com/cloudposse/terraform-aws-transit-gateway/pulls

1
1
Matt Gowie avatar
Matt Gowie

Tests are running for all and I’ve approved the the simple ones. The ram_principals one I’ll likely ask @Andriy Knysh (Cloud Posse) to review again since you were working with him originally, but it LGTM.

Matt Gowie avatar
Matt Gowie

Ah looks like because all of these PRs touch the CODEOWNERS file as part of our automation, it requires an approval from the Admins group, which means Andriy, Jeremy, or Erik need to review.

Once one of your PRs merges though, those changes will be in and then the other PRs won’t require an admin review so maybe we’ll just wait until Andriy has a minute.

1
Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

i’ll review

Andriy Knysh (Cloud Posse) avatar
Andriy Knysh (Cloud Posse)

@Alex Jurkiewicz @Matt Gowie reviewed the PRs, merged one, commented on the other two, thank you

1
1
Alex Jurkiewicz avatar
Alex Jurkiewicz

I’ve updated https://github.com/cloudposse/terraform-aws-transit-gateway/pull/18, it should be ready to merge.

I will update the other more complex PR once this is merged

1
1
Alex Jurkiewicz avatar
Alex Jurkiewicz

Updated https://github.com/cloudposse/terraform-aws-transit-gateway/pull/19 I provided more info for two of your suggestions Andriy let me know if you disagree with the approach still and I will go with your preference

Introduce new variable var.ram_principals, and deprecate
var.ram_principal. Deprecating rather than removing the old variable is
a lot more complex, code-wise, but the complexity is contained and
should ease the upgrade path for existing customers.

Fixes #14

1
1

2022-03-28

2022-03-31

    keyboard_arrow_up