md5
Repos
8
Followers
79
Following
67

Events

Created at 1 day ago
Amazon S3 Storage Lens configuration

Is this on the team;s roadmap with any sense of when it'll be added? Thanks.

It was added to the roadmap in https://github.com/hashicorp/terraform-provider-aws/pull/26166

Created at 1 day ago

Add support for outpost_config

Tweaked ConflictsWith to work with OutpostConfig

Updated Acceptance Tests

tweaked tests

Added doc updates and sample usage for outpost_config

Added doc updates and sample usage for outpost_config

rebase main

Tweaked ConflictsWith to work with OutpostConfig

Updated Acceptance Tests

tweaked tests

Added doc updates and sample usage for outpost_config

Added doc updates and sample usage for outpost_config

merged main

merged main

Merge branch 'main' into f-aws-outpost-eks-local-clusters

merge main

r/aws_identitystore_user: new resource

Create group.go

Update provider.go

Make identity_store_id required

Created at 1 day ago
Created at 2 days ago
issue comment
RDS IAM Database Authentication

FWIW, there is a gem that enables RDS IAM authentication specifically for pg via monkey patching: https://github.com/haines/pg-aws_rds_iam

Created at 3 days ago
Created at 3 days ago
Created at 4 days ago
Created at 4 days ago
Updating front end api of terraform provider from taint to taints

Your PR would introduce a breaking change to the provider. The reason the schema element is called taint is because it is configured as a block. You can have multiple taint { } blocks.

In the case of the eks_node_group data source, it is called taints because in that case it is an output from the data source.

The different between taint and taints here is in line with the resources and data sources for other services.

It would be nice if the documentation included an example of using multiple taint blocks to make this more clear.

Created at 1 week ago
issue comment
DatabaseEntriesRepository->storeExceptions updating should_display_on_index to false when it's already false

I probably should have mentioned that the database in question here was PostgreSQL. I don't think this problem affects MariaDB/MySQL in the same way.

In PostgreSQL, the constant addition of new versions of the tuples for these rows causes sequential scans on the table to take increasingly longer amounts of time as more and more versions are added. If this also results in the autovacuum process falling behind on cleaning up the table, this can result in queries for tables that nominally only have a few thousand exceptions having to scan millions of row to run the SELECT COUNT(*) or UPDATE should_display_on_index = false queries run by storeExceptions.

Created at 1 week ago

Add changelog for PR 26923

Created at 1 week ago
enhancement(rds): Support default_only, include_all, and filter for aws_rds_engine_version

Added some tests for the new additions. Here is the output of make testacc:

% make testacc AWS_PROFILE=default TESTS=TestAccRDSEngineVersionDataSource PKG=rds
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./internal/service/rds/... -v -count 1 -parallel 20 -run='TestAccRDSEngineVersionDataSource'  -timeout 180m
=== RUN   TestAccRDSEngineVersionDataSource_basic
=== PAUSE TestAccRDSEngineVersionDataSource_basic
=== RUN   TestAccRDSEngineVersionDataSource_upgradeTargets
=== PAUSE TestAccRDSEngineVersionDataSource_upgradeTargets
=== RUN   TestAccRDSEngineVersionDataSource_preferred
=== PAUSE TestAccRDSEngineVersionDataSource_preferred
=== RUN   TestAccRDSEngineVersionDataSource_defaultOnlyImplicit
=== PAUSE TestAccRDSEngineVersionDataSource_defaultOnlyImplicit
=== RUN   TestAccRDSEngineVersionDataSource_defaultOnlyExplicit
=== PAUSE TestAccRDSEngineVersionDataSource_defaultOnlyExplicit
=== RUN   TestAccRDSEngineVersionDataSource_includeAll
=== PAUSE TestAccRDSEngineVersionDataSource_includeAll
=== RUN   TestAccRDSEngineVersionDataSource_filter
=== PAUSE TestAccRDSEngineVersionDataSource_filter
=== CONT  TestAccRDSEngineVersionDataSource_basic
=== CONT  TestAccRDSEngineVersionDataSource_defaultOnlyExplicit
=== CONT  TestAccRDSEngineVersionDataSource_preferred
=== CONT  TestAccRDSEngineVersionDataSource_defaultOnlyImplicit
=== CONT  TestAccRDSEngineVersionDataSource_filter
=== CONT  TestAccRDSEngineVersionDataSource_includeAll
=== CONT  TestAccRDSEngineVersionDataSource_upgradeTargets
--- PASS: TestAccRDSEngineVersionDataSource_upgradeTargets (11.06s)
--- PASS: TestAccRDSEngineVersionDataSource_includeAll (11.07s)
--- PASS: TestAccRDSEngineVersionDataSource_filter (11.27s)
--- PASS: TestAccRDSEngineVersionDataSource_defaultOnlyExplicit (11.27s)
--- PASS: TestAccRDSEngineVersionDataSource_defaultOnlyImplicit (11.27s)
--- PASS: TestAccRDSEngineVersionDataSource_basic (11.35s)
--- PASS: TestAccRDSEngineVersionDataSource_preferred (11.59s)
PASS
ok  	github.com/hashicorp/terraform-provider-aws/internal/service/rds	14.068s
Created at 1 week ago

Add acceptance tests for aws_rds_engine_version additions

Created at 1 week ago
pull request opened
enhancement(rds): Support default_only, include_all, and filter for aws_rds_engine_version

This PR adds support for default_only, include_all, and filter to the aws_rds_engine_version data source. Adding these flags make it possible to get the default minor version given only a major version for an engine, to distinguish between provisioned and serverless engine modes, or to allow querying of deprecated versions, among other things.

Closes #19715

Created at 1 week ago
md5 create branch rds-engine-version-enhancements
Created at 1 week ago
issue comment
telescope:prune support for cockroachdb

Another problem with using ctid shows up when the rows in telescope_entries are being constantly updated under heavy exception load, as mentioned in https://github.com/laravel/telescope/issues/1251

Since the ctid is being constantly changed by UPDATE queries in this condition, the prune never actually prunes anything for the family_hash values that are being heavily updated.

Created at 1 week ago
issue comment
DatabaseEntriesRepository->storeExceptions updating should_display_on_index to false when it's already false

Going through the Open Source approval process at my employer is unfortunately too onerous to do for a simple one-line change to a project that I have no other reason to contribute to, given that we have only a handful of legacy applications built in Laravel.

I hope you will reconsider making this change yourself, since it's a clear and uncontroversial improvement for your users.

Created at 1 week ago
opened issue
DatabaseEntriesRepository->storeExceptions updating should_display_on_index to false when it's already false

The UPDATE query to set should_display_on_index = false in storeExceptions is unnecessarily updating rows where the value is already false. It would be ideal to add a where('should_display_on_index', true) condition to the update to only touch rows where it will actually be changed. Under conditions of heavy exception logging, these unnecessary updates are causing excessive load on the telescope_entries table.

Created at 2 weeks ago
IRSA credentials preferred over explicit STS session in environment variables

Describe the bug When both AWS_ROLE_ARN/AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN are set, this library is preferring the former. This causes Vault 1.4.0+ to ignore an explicitly set access key in the environment in favor of IRSA. This seems like a bug to me. If someone has gone to the trouble of exporting the access key and session token variables from an STS session, it doesn't make sense to request new credentials with IRSA. Presumably if a user has done this, they have already used the IRSA-based credentials to call sts:AssumeRole.

To Reproduce Steps to reproduce the behavior:

  1. In a Kubernetes pod with IRSA enabled, run aws sts assume-role to assume an STS role in another account
  2. Export the access key ID, secret, and session token as AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY/AWS_SESSION_TOKEN
  3. Run vault login -method=aws role=some-vault-role
  4. Receive error looking up full ARN of entity error

Having this be a cross-account scenario is key to getting the error looking up full ARN of entity error specifically, but if it isn't a cross-account role you would likely just get a failed login when the role ARN from IRSA does not match the bound ARN wildcards.

Expected behavior When AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set in the environment (and optionally AWS_SESSION_TOKEN), awsutil should ignore AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE. This is how aws sts get-caller-identity works, for example.

Created at 2 weeks ago
issue comment
Module use EC2 role instead of pod role on EKS using OIDC

@vinhlh that looks like a reasonable fix to me

Created at 1 month ago
issue comment
Modules use EC2 role instead pod role to fetch the data from S3

This issue appears to be a duplicate of https://github.com/hashicorp/terraform/issues/26292. One of them should probably be closed to consolidate any discussion.

Created at 1 month ago
issue comment
Web identity authentication support for S3 module

From that issue on go-getter, it looks like this issue may actually be a duplicate of https://github.com/hashicorp/terraform/issues/28101 (or vice versa)

Created at 1 month ago
issue comment
Web identity authentication support for S3 module

This functionality is handled in the go-getter module. Here is a related issue in that module, which is where I believe this would actually need to be fixed: https://github.com/hashicorp/go-getter/issues/313

Created at 1 month ago