all resources: Grant object owners to connected user when needed. #146
Conversation
ghost
added
the
cyrilgdn
force-pushed
the
grant-rds
branch
3 times, most recently
from
dae47fe to
60ef095
Compare
Sorry for the dreadfully late reply. Do you still need testing against an rds instance? If so, is it sufficient to just spin up a "free-tier" and point the tests to this or are you looking for something more detailed? |
@slocke716 It was more if you can easily test and assert it fixes the specific use case you created your PR for. We're using this patched version against RDS so I know it works but maybe you have a specific use case that we are not covering neither does the acceptance tests. |
If the configured admin user in the provider is not superuser, we need to temporarily grant to it the roles owning objects we are modifying.
We fixed a lot of problems for the non-superuser RDS `postgres` role so it's the best way to test it.
It tries to connect psql instead of just parsing logs so we are sure database is ready.
Co-authored-by: Joe Marty <joe.marty@smartersorting.com>
|
FYI, this has just been released in v1.7.0. |
|
It works! Thank you so much for this amazing birthday gift! 🙏 |
This should fix most of permissions problems the provider has when running against RDS databases (and maybe other Cloud provider, but didn't test yet)
This also adds a new run of integration tests against a RDS-like Postgres.
Some tests are disabled for this environment, either because it really need to be superuser (e.g. to create a new superuser) or because the environment is not totally similar as RDS (e.g.: for the extensions, I need to check how I can reproduce RDS behavior).
This replaces #139 and #135
Thanks to @slocke716 and @rimmington for your work on these problems that help me to create a more generic fix. If you have time to test this PR on your environment to assert it fixes your use cases, and even more to make a review of this PR, it would be very helpful 😊 .
This (hopefully) fixes #36