feat!: Aligned the behaviour of additional_users resource in all 3 Cloud SQL instance modules.

[ravisiddhu]

This PR is in response to #222

Buganizer bug : http://b/259914601

In mssql module, there was no way to generate random password for the user. the password was a required field, hence couldn't omit it.
If password is set as null, then no password is created for the user, and if the password is set as "", then the password is also literally "" (empty password).

I am aligning the behaviour of additonal_users resource in all 3 cloud sql modules.

This PR include BREAKING CHANGES :-

1. Addition of new field called random_password in additional_users resource.
2. Added support for creation of IAM users in MySQL.
3. The same modified additional_users resource is used in all the 3 modules.

Please merge this PR with breaking changes only when we are releasing the next major version.

[bharathkkb]

We had received some feedback that not having vars typed hurt UX as users were unable to determine what values to pass in. WDYT about switching to use optionals instead? This will be breaking change requiring 1.3.0 but we expect most modules to switch to use optionals next year.

[ravisiddhu]

I don't think we should force all our customers to upgrade terraform to 1.3.0+, for a small fearure fix. I think we should wait and only cause this breaking change when it is absolutely necessary, wdyt?

As an alternate solution we can have one more resource called "additional_users_with_random_password", where users can set null or "" to the password field to generate random password (replicating the behavior of postgres module) in mssql module. In this way we are not breaking anything for the exisiting mssql customers, what do you think? Should I go forward with this?

[bharathkkb]

We will likely switch to 1.3 in the next breaking release as we had multiple breaking major releases (12.0,11.0,10.0,8.0) due to changes in object types which 1.3 will avoid. Agreed we don't need to force the switch for this feature, I was thinking of bundling this with next major if we decided to use optionals.

With the alternate approach using additional_users_with_random_password, would we need a new input to target this? Also re reading the description, I suspect most users may not want to use a literal "" since no password is supported by null. It might just be cleaner to not support literal "".

[ravisiddhu]

Setting password as "", creates an user with an empty password, then that user can login without providing password.

1. Should I use Optionals and send the PR, where you can merge this PR once we decide to create a breaking release. or
2. With additional_users_with_random_password, yes, it would be a new input field for the customer. Now mssql customers could either use additonal_users or additonal_users_with_random_password input fields for creating users. The mssql customers can use the new input if they require their users to be set with an random password (and they still would have the option to change the random password if needed. This new field would replicate the behaviour of additional_users field in postgres module).

Should I go ahead with (1) or (2) ?

[bharathkkb]

If password is set as null, then no password is created for the user, and if the password is set as "", then the password is also literally "" (empty password).

Setting password as "", creates an user with an empty password, then that user can login without providing password.

In that case, what is the difference between empty string "" as password vs no password at all via null?

I am wondering even with optionals we will need to provide a default value signifying when to generate the random password - would we use empty string or null?

[ravisiddhu]

In postgres module, random password is generated during empty string and null values for password.

In MySQL, random password is generated only when password field is not set in the additional_users resource, since additional_users is of type list(map(any), it is possible to not set the pwd field.

In mssql, random password is never generated, and a login user without pwd is created if the customer set the pwd as null or "".

I tried using "Optionals", but optionals also just force set the value of unset optional fields as null. So again if the customer does not set the password, it would only create a login user without pwd.

If we change the existing behaviour in mssql, that is to produce a random password for the user if the customer sets the password as null or "", then it would be a breaking change if the customers were in fact actually setting null or "" to pwd field to create a password-less login users.

I think creating a new resource called "additional_users_with_random_password" in mssql module would help to create users with random pwd without any breaking change. what do you think?

[comment-bot-dev]

@ravisiddhu
Thanks for the PR! 🚀
✅ Lint checks have passed.