pasali
Repos
71
Followers
57
Following
19

Events

issue comment
Support hook scripts for user and password

It's actually about our organizational flow which we use to deploy both code changes and schema changes. And the both action done by the developers also. We use feature-based development to rollout microservices so when we decided to automate schema changes as well we thought it would be best for us to create similar flow. That why we used folder level separation for environments. And i think it's more declarative like this because some host names can be long and would be meaningless to developer. This way they are more confident about where their changes going to deploy.

Created at 1 day ago
issue comment
Support hook scripts for user and password

That's only the case if each schema on the same host needs a different user, which isn't too common. Since Skeema is automation, ideally it should be executed with a user who can see/interact with all the schemas on a database instance. In that case you can just define the host, user, password in the .skeema file of the "host level" parent directory, and it will cascade down to the schema subdirs.

This is also good solution but i prefer to keep my folder structure like this:

prod/
   foo/(host A)
   bar/(host A)
   baz/(host B)
test/
   foo/(host C)
   bar/(host C)
   baz/(host D)

Adding another folder level for host might reduce readability so i am OK with separate files. :)

But IMHO environment variable abstraction might save you from adding hook support at all. Because after this user can use whatever he/she likes to populate environment variables.

Created at 3 days ago
issue comment
Support hook scripts for user and password

This is actually resolves my use-case. But there is one thing that i want to mention; if there is multiple schemas on the same host, user need to define these variables on multiple .skeema files. I think it would be nice if skeema introduce a environment variable convetion like SKEEMA_<host>_USER and SKEEMA_<host>_PASSWORD to look up variables even they aren't static definition. Thank you for your work. :)

Created at 6 days ago
pasali create tag 9.1.0
Created at 1 month ago

Remove redundant packages

Created at 1 month ago
Update release credentials to GH credentials
Created at 2 months ago
http_tokens=required may cause Access Denied error if you are using an older SDK version after the change to IMDSv2

I see your point but i think IMDS settings tend to be go unnoticed than any other changes to module. You can clearly see whats changed in security groups rules but this setting can be missed. It maybe helpful if IMDS endpoint setting changes could be mentioned in migration documentation.

Created at 2 months ago
http_tokens=required may cause Access Denied error if you are using an older SDK version after the change to IMDSv2

Versions

  • Module version [Required]: 18.29.0
  • Terraform version: Terraform v1.2.6
  • Provider version(s): provider registry.terraform.io/hashicorp/aws v4.9.0

Reproduction Code [Required]

https://github.com/terraform-aws-modules/terraform-aws-eks/blob/57bb667f20e072bb1a6ca1ffa9beef6052895acb/node_groups.tf#L3-L5 Setting http_tokens=required is forcing usage of IMDSv2 and if your SDK is not update to use IMDSv2, your app going to have access problems with AWS services. In my case it was S3.

Expected behavior

I think the default value should be optional for a safe migration from 17.x.x to 18.x.x

Created at 2 months ago