Correct paths at terraform topology configs #45
Conversation
|
I'd finish this off but I'm not entirely sure why the state would change here 😄 |
|
The problem is resources in the existing terraform states are named differently after the update that introduced AWS topologies modules. If we do that kind of change, we would normally want to add a migration script to upgrade the existing states so that they're compatible. Without it, terraform will abort due to conflicts at the planing state (this can be considered a good case) or at application due to conflicting uniqueness constraints at AWS (a worse case, since it's not caught at planning). The second case is only possible if we remove the state instead of upgrading it. I wanted to spend some time to assess whether we'll hit the second issue if I just drop the states, but it seems like we can just do that and see if we'll have troubles. We'll be facing this same issue if we don't introduce state migration logic or be careful with the changes we do at terraform. I'm not sure though it's worth the engineering time to implement, or we can just handle issues each time this happens manually. |
|
Ah, wasn't aware. Everything in our test harness should be ephemeral so I don't want to spend time migrating state if it's difficult. We should be able to delete everything and start over (minus the test data). Regarding shared state, I'm wondering if we even need this. I'm curious if it would be easier for each user to have their own state file, even for global state. My only concern is the new long running tests that @lukesteensen is introducing. |
|
It would be great if we can make the test harness truly ephemeral, however we need a better way of cleaning up before that will be possible. Currently, only the VM is removed by the alert timeout. I agree we shouldn't really have that state shared, however, without shared state and proper cleanup each test leaves a bit of garbage, quickly exhausting the AWS quotas. |
|
Regarding the long-running tests, I think they should be managed somehow explicitly separately from the regular short running tests. That is to avoid disrupting their execution by accident. I'll address this concern after we have the #44 merged. |
Use this at your own risk! It's counter-intuitive, but local references to the remote terraform state are currently shared accross user_id and test_configuration, and you should not migrate them! Instead, clear local state when switching the configuration or user id. It'll be addressed in the future.
This is a WIP, terraform state that we have at S3 has to be migrated so it doesn't diverge. Or it has to be reset, either one would work for us I guess.
I'll take care of it, and then we can merge this.