Add redshift_database resource and data source.

[sworisbreathing]

Currently the redshift database resource only supports local databases, while the data source supports both local and datashare databases. I'm still trying to figure out whether it's best to manage datashare databases in the same resource definition or a separate one. (edit: this is now working well with a nested configuration block for the datashare. if you go from non-datashare to datashare, or change anything in the datashare block, it will force-new)

The COLLATE CASE_SENSITIVE/CASE_INSENSITIVE option isn't yet supported as there doesn't seem to be a way to read it back that I can find (I've opened a support ticket with AWS about it to see if there's a way) Redshift only allows you to change it (i.e. ALTER DATABASE foo COLLATE CASE_INSENSITIVE) for the database you're currently connected to... you can't change it for other databases in the cluster.

(edit: what I thought was the inability to read the setting turned out to be my sql client's inability to render text[] columns properly)

[sworisbreathing]

Update: I've got some local changes working more or less for creating databases from datashares, however I still have some cleanup work to do on the changes so I haven't pushed the code up to my fork yet. Will try and close it off tomorrow.

One issue I can see is that acceptance testing the datashare stuff is much more complicated:

• both the producer and consumer cluster must be in the RA3 family (DS2 and DC2 don't support data sharing)
• you have to create a data share on the producer first and reference its namespace on the consumer, so either the acceptance test is going to leak a fair amount of info about my environment (which my security team wouldn't like) or it would need to spin up a producer cluster as part of the test and create a datashare on it (which is complicated, since I haven't started the work yet to add a redshift_datashare resource)

[sworisbreathing]

Okay everything looks good now except for test coverage of a datashare database. For those I'm still not quite sure how to proceed, especially in light of the fact that terraform-provider-aws doesn't seem to expose the cluster namespace in the aws_redshift_cluster resource/data-source, so tests would either need the value hardcoded or resolved through environment variables.

[winglot]

Okay everything looks good now except for test coverage of a datashare database. For those I'm still not quite sure how to proceed, especially in light of the fact that terraform-provider-aws doesn't seem to expose the cluster namespace in the aws_redshift_cluster resource/data-source, so tests would either need the value hardcoded or resolved through environment variables.

I know that would require some additional work, but how about a new data source (eg. redshift_current_namespace) that would return the current cluster namespace? It's possible with a CURRENT_NAMESPACE call https://docs.aws.amazon.com/redshift/latest/dg/r_CURRENT_NAMESPACE.html

edit: Just realized that this would only work if you manage multiple redshift clusters from single terraform repo. In case of multiple repos, you would have to export the value from the data source to output in terraform and do a cross-state reading of the output value.

[sworisbreathing]

I know that would require some additional work, but how about a new data source (eg. redshift_current_namespace) that would return the current cluster namespace? It's possible with a CURRENT_NAMESPACE call https://docs.aws.amazon.com/redshift/latest/dg/r_CURRENT_NAMESPACE.html

Yeah I was planning to do that as part of my work on data shares (separate PR)

edit: Just realized that this would only work if you manage multiple redshift clusters from single terraform repo. In case of multiple repos, you would have to export the value from the data source to output in terraform and do a cross-state reading of the output value.

I prefer the first approach, that is using multiple provider configurations in the same repo (one for the producer and one for each consumer)