Commit Graph

12 Commits

Author SHA1 Message Date
James Bardin
ea095eda87 change to default state after backend migration
When migrating from a multi-state backend to a single-state backend, we
have to ensure that our locally configured environment is changed back
to "default", or we won't be able to access the new backend.
2017-03-16 15:55:32 -04:00
Mitchell Hashimoto
1e3d452613 command: multistate to multistate conversions 2017-03-01 12:35:59 -08:00
Mitchell Hashimoto
c82d7dd56c command: multi-state (non-default env) to single state 2017-03-01 11:40:28 -08:00
Mitchell Hashimoto
e75b666591 command: test multi-state to single state 2017-03-01 11:34:45 -08:00
Mitchell Hashimoto
3ef82e6b5f command: test multi-state with default only to single state 2017-03-01 11:08:39 -08:00
Mitchell Hashimoto
1d8b76c89d command: initial work on migrating envs, basic cases first 2017-03-01 10:59:17 -08:00
James Bardin
a372e9c54b fix state migration lock info 2017-02-15 17:00:54 -05:00
James Bardin
f5ed8cd288 Use NewLockInfo to get a pre-populated value
Using NewLockInfo ensure we start with all required fields filled.
2017-02-15 14:41:55 -05:00
James Bardin
4f0c465187 make command tests pass with new state.Locker 2017-02-15 14:41:55 -05:00
Mitchell Hashimoto
90f3d40c1f command: use new state lock/unlock helpers for better UX 2017-02-14 11:33:55 -08:00
James Bardin
0c1b138719 Add state locking during backend init
During backend initialization, especially during a migration, there is a
chance that an existing state could be overwritten.

Attempt to get a locks when writing the new state. It would be nice to
always have a lock when reading the states, but the recursive structure
of the Meta.Backend config functions makes that quite complex.
2017-02-09 15:47:27 -05:00
Mitchell Hashimoto
9654387771 command: meta.Backend is used for initializing the backend
This is a complex function that handles all the potential cases that can
happen with legacy remote state, new configurations, etc.
2017-01-26 14:33:49 -08:00