Rename DB variables

[pditommaso]

Let's rename those variables:

• db_master_username-> db_root_username
• db_master_password-> db_root_password
• db_name-> db_app_schema
• db_username-> db_app_username
• db_password-> db_app_password

[pditommaso]

Rationale:

• the word "master" is considered offensive in some communities. It should be avoid https://www.wired.com/story/tech-confronts-use-labels-master-slave/
• db_ to db_app_ make it simpler to distinguish from the others

[enekui]

Please, note that the naming convention that I am using is to keep consistency with AWS and Terraform RDS database resources. Also, since we are using official AWS modules, I keep the same naming convention that they use in the module parameters to keep consistency across all the code. This is a best practice that allow us to keep the code clean and easy to debug, scale, and support. As an example of that: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#master_password https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/rds_cluster#master_username And I add the db prefix since this is the relevant to our module. Same for AWS console, and API.

Kindly note that this module is intended to be publicly used, so we need to take care of all the Terraform and AWS good practices as we can see in other AWS terraform modules. You can see here, in the Terraform RDS module that we are using how they use db_name, we need to be consistent with it since it's the official AWS module that we are using to power our module. https://github.com/terraform-aws-modules/terraform-aws-rds#input_db_name I truly hope this explanation can clarify the reasoning behind the naming convention that I am using.

[pditommaso]

Note, we'll need to make this available also for GKE and and Azure. Each of those will have their own convention, so we need to have own convention

[enekui]

Note, we'll need to make this available also for GKE and and Azure. Each of those will have their own convention, so we need to have own convention

Yes, but this module can't handle another cloud. For Azure and Google, we need to create different modules.

[pditommaso]

Indeed, but I think we should not use a different set of variables across those modules.

[enekui]

Indeed, but I think we should not use a different set of variables across those modules.

At the end of the day, I will do what you say. But note that the variable naming should always be driven by the underlying module, and by the naming convention of the cloud provider. If you want us to use those variables you mentioned above, I will do it. There is no point in making this thread longer.

[pditommaso]

But note that the variable naming should always be driven by the underlying module

Don't agree on this, also because the author of the module we have own conventions

[enekui]

Done. Just changed db_app_schema to db_app_schema_name to be more consistent with variable naming.