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.
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.
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>_PASSWORD to look up variables even they aren't static definition.
Thank you for your work. :)
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.
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.
I think the default value should be
optional for a safe migration from 17.x.x to 18.x.x