resilien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
terraform/command/state_mv_test.go

1372 lines
33 KiB
Go
Raw Normal View History

command/state mv
2016-04-12 20:44:12 +02:00
package command
import (
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
"fmt"
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
"os"
command/state mv
2016-04-12 20:44:12 +02:00
"path/filepath"
command/state: update and fix the state mv command
2018-10-25 15:41:00 +02:00
"strings"
command/state mv
2016-04-12 20:44:12 +02:00
"testing"
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
"github.com/mitchellh/cli"
"github.com/hashicorp/terraform/addrs"
test that `state mv -state` doesn't use Backend If we provide a -state flag to a state command, we do not want terraform to modify the backend state. This test fails since the state specified in the backend doesn't exist
2017-06-23 20:39:37 +02:00
"github.com/hashicorp/terraform/helper/copy"
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
"github.com/hashicorp/terraform/states"
command/state mv
2016-04-12 20:44:12 +02:00
"github.com/hashicorp/terraform/terraform"
)
func TestStateMv(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
command/state mv
2016-04-12 20:44:12 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "baz",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
Dependencies: []addrs.AbsResource{mustResourceAddr("test_instance.foo")},
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
command/state mv
2016-04-12 20:44:12 +02:00
statePath := testStateFile(t, state)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
command/state mv
2016-04-12 20:44:12 +02:00
},
}
args := []string{
"-state", statePath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, testStateMvOutput)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvOutputOriginal)
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
func TestStateMv_resourceToInstance(t *testing.T) {
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "baz",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
Dependencies: []addrs.AbsResource{mustResourceAddr("test_instance.foo")},
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
)
s.SetResourceMeta(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "bar",
}.Absolute(addrs.RootModuleInstance),
states.EachList,
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
)
})
statePath := testStateFile(t, state)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-state", statePath,
"test_instance.foo",
"test_instance.bar[0]",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, `
test_instance.bar.0:
ID = bar
provider = provider.test
bar = value
foo = value
test_instance.baz:
ID = foo
provider = provider.test
bar = value
foo = value
`)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvOutputOriginal)
}
func TestStateMv_instanceToResource(t *testing.T) {
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(0)).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "baz",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
)
})
statePath := testStateFile(t, state)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-state", statePath,
"test_instance.foo[0]",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, `
test_instance.bar:
ID = bar
provider = provider.test
bar = value
foo = value
test_instance.baz:
ID = foo
provider = provider.test
bar = value
foo = value
`)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], `
test_instance.baz:
ID = foo
provider = provider.test
bar = value
foo = value
test_instance.foo.0:
ID = bar
provider = provider.test
bar = value
foo = value
`)
}
Allow moving instances to new resources If a state mv target happens to be a resource that doesn't exist, allow the creation of the new resource inferring the EachMode from the target address.
2019-12-05 22:06:25 +01:00
func TestStateMv_instanceToNewResource(t *testing.T) {
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(0)).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
Allow moving instances to new resources If a state mv target happens to be a resource that doesn't exist, allow the creation of the new resource inferring the EachMode from the target address.
2019-12-05 22:06:25 +01:00
)
})
statePath := testStateFile(t, state)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-state", statePath,
"test_instance.foo[0]",
"test_instance.bar[\"new\"]",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, `
test_instance.bar["new"]:
ID = bar
provider = provider.test
bar = value
foo = value
`)
// now move the instance to a new resource in a new module
args = []string{
"-state", statePath,
"test_instance.bar[\"new\"]",
"module.test.test_instance.baz[\"new\"]",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, `
<no state>
module.test:
test_instance.baz["new"]:
ID = bar
provider = provider.test
bar = value
foo = value
`)
}
command/state: update and fix the state mv command
2018-10-25 15:41:00 +02:00
func TestStateMv_differentResourceTypes(t *testing.T) {
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
command/state: update and fix the state mv command
2018-10-25 15:41:00 +02:00
)
})
statePath := testStateFile(t, state)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-state", statePath,
"test_instance.foo",
"test_network.bar",
}
if code := c.Run(args); code == 0 {
t.Fatalf("expected error output, got:\n%s", ui.OutputWriter.String())
}
command: Fix various issues in the "terraform state ..." subcommands In earlier refactoring we updated these commands to support the new address and state types, but attempted to partially retain the old-style "StateFilter" abstraction that originally lived in the Terraform package, even though that was no longer being used for any other functionality. Unfortunately the adaptation of the existing filtering to the new types wasn't exact and so these commands ended up having a few bugs that were not covered by the existing tests. Since the old StateFilter behavior was the source of various misbehavior anyway, here it's removed altogether and replaced with some simpler functions in the state_meta.go file that are tailored to the use-cases of these sub-commands. As well as just generally behaving more consistently with the other parts of Terraform that use the new resource address types, this commit fixes the following bugs: - A resource address of aws_instance.foo would previously match an resource of that type and name in any module, which disagreed with the expected interpretation elsewhere of meaning a single resource in the root module. - The "terraform state mv" command was not supporting moves from a single resource address to an indexed address and vice-versa, because the old logic didn't need to make that distinction while they are two separate address types in the new logic. Now we allow resources that do not have count/for_each to be treated as if they are instances for the purposes of this command, which is a better match for likely user intent and for the old behavior. Finally, we also clean up a little some of the usage output from these commands, which hasn't been updated for some time and so had both some stale information and some inaccurate terminology.
2019-03-16 03:51:26 +01:00
if !strings.Contains(ui.ErrorWriter.String(), "resource types don't match") {
command/state: update and fix the state mv command
2018-10-25 15:41:00 +02:00
t.Fatalf("expected initialization error, got:\n%s", ui.ErrorWriter.String())
}
}
test that `state mv -state` doesn't use Backend If we provide a -state flag to a state command, we do not want terraform to modify the backend state. This test fails since the state specified in the backend doesn't exist
2017-06-23 20:39:37 +02:00
// don't modify backend state is we supply a -state flag
func TestStateMv_explicitWithBackend(t *testing.T) {
td := tempDir(t)
copy.CopyDir(testFixturePath("init-backend"), td)
defer os.RemoveAll(td)
defer testChdir(t, td)()
backupPath := filepath.Join(td, "backup")
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
test that `state mv -state` doesn't use Backend If we provide a -state flag to a state command, we do not want terraform to modify the backend state. This test fails since the state specified in the backend doesn't exist
2017-06-23 20:39:37 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "baz",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
test that `state mv -state` doesn't use Backend If we provide a -state flag to a state command, we do not want terraform to modify the backend state. This test fails since the state specified in the backend doesn't exist
2017-06-23 20:39:37 +02:00
statePath := testStateFile(t, state)
// init our backend
ui := new(cli.MockUi)
ic := &InitCommand{
Meta: Meta{
testingOverrides: metaOverridesForProvider(testProvider()),
Ui: ui,
},
}
args := []string{}
if code := ic.Run(args); code != 0 {
t.Fatalf("bad: \n%s", ui.ErrorWriter.String())
}
// only modify statePath
p := testProvider()
ui = new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
test that `state mv -state` doesn't use Backend If we provide a -state flag to a state command, we do not want terraform to modify the backend state. This test fails since the state specified in the backend doesn't exist
2017-06-23 20:39:37 +02:00
},
}
args = []string{
"-backup", backupPath,
"-state", statePath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, testStateMvOutput)
}
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
func TestStateMv_backupExplicit(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "baz",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
Dependencies: []addrs.AbsResource{mustResourceAddr("test_instance.foo")},
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
statePath := testStateFile(t, state)
command/state: update and fix the state mv command
2018-10-25 15:41:00 +02:00
backupPath := statePath + ".backup.test"
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
},
}
args := []string{
"-backup", backupPath,
"-state", statePath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, statePath, testStateMvOutput)
don't load the backend when -state is provided When using a `state` command, if the `-state` flag is provided we do not want to modify the Backend state. In this case we should always create a local state instance. The backup flag was also being ignored, and some tests were relying on that, which have been fixed.
2017-06-23 20:41:49 +02:00
// Test backup
command/state: mv and rm -backup works Fixes #12154 The "-backup" flag before for "state *" CLI had some REALLY bizarre behavior: it would change the _destination_ state and actually not create any additional backup at all (the original state was unchanged and the normal timestamped backup still are written). Really weird. This PR makes the -backup flag work as you'd expect with one caveat: we'll _still_ create the timestamped backup file. The timestamped backup file helps make sure that you always get a backup history when using these commands. We don't want to make it easy for you to overwrite a state with the `-backup` flag.
2017-02-22 06:10:03 +01:00
testStateOutput(t, backupPath, testStateMvOutputOriginal)
}
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
func TestStateMv_stateOutNew(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
statePath := testStateFile(t, state)
stateOutPath := statePath + ".out"
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
},
}
args := []string{
"-state", statePath,
"-state-out", stateOutPath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, stateOutPath, testStateMvOutput_stateOut)
testStateOutput(t, statePath, testStateMvOutput_stateOutSrc)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvOutput_stateOutOriginal)
}
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
func TestStateMv_stateOutExisting(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
stateSrc := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
statePath := testStateFile(t, stateSrc)
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
stateDst := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "qux",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar"}`),
Status: states.ObjectReady,
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
stateOutPath := testStateFile(t, stateDst)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
},
}
args := []string{
"-state", statePath,
"-state-out", stateOutPath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, stateOutPath, testStateMvExisting_stateDst)
testStateOutput(t, statePath, testStateMvExisting_stateSrc)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvExisting_stateSrcOriginal)
backups = testStateBackups(t, filepath.Dir(stateOutPath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvExisting_stateDstOriginal)
}
command/state mv
2016-04-12 20:44:12 +02:00
func TestStateMv_noState(t *testing.T) {
tmp, cwd := testCwd(t)
defer testFixCwd(t, tmp, cwd)
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
command/state mv
2016-04-12 20:44:12 +02:00
},
}
args := []string{"from", "to"}
if code := c.Run(args); code != 1 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
}
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
func TestStateMv_stateOutNew_count(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(0)).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(1)).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "bar",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
statePath := testStateFile(t, state)
stateOutPath := statePath + ".out"
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
},
}
args := []string{
"-state", statePath,
"-state-out", stateOutPath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, stateOutPath, testStateMvCount_stateOut)
testStateOutput(t, statePath, testStateMvCount_stateOutSrc)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvCount_stateOutOriginal)
}
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
// Modules with more than 10 resources were sorted lexically, causing the
// indexes in the new location to change.
func TestStateMv_stateOutNew_largeCount(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
// test_instance.foo has 11 instances, all the same except for their ids
for i := 0; i < 11; i++ {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(i)).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(fmt.Sprintf(`{"id":"foo%d","foo":"value","bar":"value"}`, i)),
Status: states.ObjectReady,
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
}
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "bar",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
statePath := testStateFile(t, state)
stateOutPath := statePath + ".out"
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
},
}
args := []string{
"-state", statePath,
"-state-out", stateOutPath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, stateOutPath, testStateMvLargeCount_stateOut)
testStateOutput(t, statePath, testStateMvLargeCount_stateOutSrc)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvLargeCount_stateOutOriginal)
}
terraform: state mv tests
2016-08-18 21:05:42 +02:00
func TestStateMv_stateOutNew_nestedModule(t *testing.T) {
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance.Child("foo", addrs.NoKey).Child("child1", addrs.NoKey)),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
terraform: state mv tests
2016-08-18 21:05:42 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance.Child("foo", addrs.NoKey).Child("child2", addrs.NoKey)),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
terraform: state mv tests
2016-08-18 21:05:42 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
terraform: Ugly huge change to weave in new State and Plan types Due to how often the state and plan types are referenced throughout Terraform, there isn't a great way to switch them out gradually. As a consequence, this huge commit gets us from the old world to a _compilable_ new world, but still has a large number of known test failures due to key functionality being stubbed out. The stubs here are for anything that interacts with providers, since we now need to do the follow-up work to similarly replace the old terraform.ResourceProvider interface with its replacement in the new "providers" package. That work, along with work to fix the remaining failing tests, will follow in subsequent commits. The aim here was to replace all references to terraform.State and its downstream types with states.State, terraform.Plan with plans.Plan, state.State with statemgr.State, and switch to the new implementations of the state and plan file formats. However, due to the number of times those types are used, this also ended up affecting numerous other parts of core such as terraform.Hook, the backend.Backend interface, and most of the CLI commands. Just as with 5861dbf3fc49b19587a31816eb06f511ab861bb4 before, I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.
2018-08-14 23:24:45 +02:00
)
})
terraform: state mv tests
2016-08-18 21:05:42 +02:00
statePath := testStateFile(t, state)
stateOutPath := statePath + ".out"
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
Make the state commands use the real command.Meta In order to use a backend for the state commands, we need an initialized meta. Use a single Meta instance rather than temporary ones to make sure the backends are initialized properly.
2017-07-26 19:08:09 +02:00
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
terraform: state mv tests
2016-08-18 21:05:42 +02:00
},
}
args := []string{
"-state", statePath,
"-state-out", stateOutPath,
"module.foo",
"module.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, stateOutPath, testStateMvNestedModule_stateOut)
testStateOutput(t, statePath, testStateMvNestedModule_stateOutSrc)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvNestedModule_stateOutOriginal)
}
allow moving resource to new modules not in state Create the missing modules in the state when moving resources to a module that doesn't yet exist. This allows for refactoring of configuration into new modules, without having to create dummy resources in the module before the "state mv" operations.
2019-08-02 00:54:09 +02:00
func TestStateMv_toNewModule(t *testing.T) {
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "bar",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
allow moving resource to new modules not in state Create the missing modules in the state when moving resources to a module that doesn't yet exist. This allows for refactoring of configuration into new modules, without having to create dummy resources in the module before the "state mv" operations.
2019-08-02 00:54:09 +02:00
)
})
statePath := testStateFile(t, state)
stateOutPath1 := statePath + ".out1"
stateOutPath2 := statePath + ".out2"
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-state", statePath,
"-state-out", stateOutPath1,
"test_instance.bar",
"module.bar.test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
// Test it is correct
testStateOutput(t, stateOutPath1, testStateMvNewModule_stateOut)
testStateOutput(t, statePath, testStateMvNestedModule_stateOutSrc)
// Test we have backups
backups := testStateBackups(t, filepath.Dir(statePath))
if len(backups) != 1 {
t.Fatalf("bad: %#v", backups)
}
testStateOutput(t, backups[0], testStateMvNewModule_stateOutOriginal)
// now verify we can move the module itself
args = []string{
"-state", stateOutPath1,
"-state-out", stateOutPath2,
"module.bar",
"module.foo",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
testStateOutput(t, stateOutPath2, testStateMvModuleNewModule_stateOut)
}
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
add tests for state commands through a backend
2017-07-27 21:31:13 +02:00
func TestStateMv_withinBackend(t *testing.T) {
td := tempDir(t)
copy.CopyDir(testFixturePath("backend-unchanged"), td)
defer os.RemoveAll(td)
defer testChdir(t, td)()
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
state := states.BuildState(func(s *states.SyncState) {
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"bar","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
add tests for state commands through a backend
2017-07-27 21:31:13 +02:00
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
)
s.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "baz",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
AttrsJSON: []byte(`{"id":"foo","foo":"value","bar":"value"}`),
Status: states.ObjectReady,
Dependencies: []addrs.AbsResource{mustResourceAddr("test_instance.foo")},
},
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978) * Introduce "Local" terminology for non-absolute provider config addresses In a future change AbsProviderConfig and LocalProviderConfig are going to become two entirely distinct types, rather than Abs embedding Local as written here. This naming change is in preparation for that subsequent work, which will also include introducing a new "ProviderConfig" type that is an interface that AbsProviderConfig and LocalProviderConfig both implement. This is intended to be largely just a naming change to get started, so we can deal with all of the messy renaming. However, this did also require a slight change in modeling where the Resource.DefaultProviderConfig method has become Resource.DefaultProvider returning a Provider address directly, because this method doesn't have enough information to construct a true and accurate LocalProviderConfig -- it would need to refer to the configuration to know what this module is calling the provider it has selected. In order to leave a trail to follow for subsequent work, all of the changes here are intended to ensure that remaining work will become obvious via compile-time errors when all of the following changes happen: - The concept of "legacy" provider addresses is removed from the addrs package, including removing addrs.NewLegacyProvider and addrs.Provider.LegacyString. - addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded in it and has an addrs.Provider and a string alias directly instead. - The provider-schema-handling parts of Terraform core are updated to work with addrs.Provider to identify providers, rather than legacy strings. In particular, there are still several codepaths here making legacy provider address assumptions (in order to limit the scope of this change) but I've made sure each one is doing something that relies on at least one of the above changes not having been made yet. * addrs: ProviderConfig interface In a (very) few special situations in the main "terraform" package we need to make runtime decisions about whether a provider config is absolute or local. We currently do that by exploiting the fact that AbsProviderConfig has LocalProviderConfig nested inside of it and so in the local case we can just ignore the wrapping AbsProviderConfig and use the embedded value. In a future change we'll be moving away from that embedding and making these two types distinct in order to represent that mapping between them requires consulting a lookup table in the configuration, and so here we introduce a new interface type ProviderConfig that can represent either AbsProviderConfig or LocalProviderConfig decided dynamically at runtime. This also includes the Config.ResolveAbsProviderAddr method that will eventually be responsible for that local-to-absolute translation, so that callers with access to the configuration can normalize to an addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's currently unused because existing callers are still relying on the simplistic structural transform, but we'll switch them over in a later commit. * rename LocalType to LocalName Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
addrs.LocalProviderConfig{LocalName: "test"}.Absolute(addrs.RootModuleInstance),
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
)
})
add tests for state commands through a backend
2017-07-27 21:31:13 +02:00
// the local backend state file is "foo"
statePath := "local-state.tfstate"
backupPath := "local-state.backup"
f, err := os.Create(statePath)
if err != nil {
t.Fatal(err)
}
defer f.Close()
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
if err := writeStateForTesting(state, f); err != nil {
add tests for state commands through a backend
2017-07-27 21:31:13 +02:00
t.Fatal(err)
}
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-backup", backupPath,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
testStateOutput(t, statePath, testStateMvOutput)
testStateOutput(t, backupPath, testStateMvOutputOriginal)
}
func TestStateMv_fromBackendToLocal(t *testing.T) {
td := tempDir(t)
copy.CopyDir(testFixturePath("backend-unchanged"), td)
defer os.RemoveAll(td)
defer testChdir(t, td)()
state := &terraform.State{
Modules: []*terraform.ModuleState{
&terraform.ModuleState{
Path: []string{"root"},
Resources: map[string]*terraform.ResourceState{
"test_instance.foo": &terraform.ResourceState{
Type: "test_instance",
Primary: &terraform.InstanceState{
ID: "bar",
Attributes: map[string]string{
"foo": "value",
"bar": "value",
},
},
},
"test_instance.baz": &terraform.ResourceState{
Type: "test_instance",
Primary: &terraform.InstanceState{
ID: "foo",
Attributes: map[string]string{
"foo": "value",
"bar": "value",
},
},
},
},
},
},
}
// the local backend state file is "foo"
statePath := "local-state.tfstate"
// real "local" state file
statePathOut := "real-local.tfstate"
f, err := os.Create(statePath)
if err != nil {
t.Fatal(err)
}
defer f.Close()
if err := terraform.WriteState(state, f); err != nil {
t.Fatal(err)
}
p := testProvider()
ui := new(cli.MockUi)
c := &StateMvCommand{
StateMeta{
Meta: Meta{
testingOverrides: metaOverridesForProvider(p),
Ui: ui,
},
},
}
args := []string{
"-state-out", statePathOut,
"test_instance.foo",
"test_instance.bar",
}
if code := c.Run(args); code != 0 {
t.Fatalf("bad: %d\n\n%s", code, ui.ErrorWriter.String())
}
testStateOutput(t, statePathOut, testStateMvCount_stateOutSrc)
// the backend state should be left with only baz
testStateOutput(t, statePath, testStateMvOriginal_backend)
}
command/state mv
2016-04-12 20:44:12 +02:00
const testStateMvOutputOriginal = `
test_instance.baz:
ID = foo
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command/state mv
2016-04-12 20:44:12 +02:00
bar = value
foo = value
remove stale dependencies on `state mv` Clear any Dependencies if there is an entry matching a `state mv` from address. While stale dependencies won't directly effect any current operations, clearing the list will allow them to be recreated in their entirety during refresh. This will help future releases that may rely solely on the pre-calculated dependencies for destruction ordering.
2020-01-04 14:29:25 +01:00
Dependencies:
test_instance.foo
command/state mv
2016-04-12 20:44:12 +02:00
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command/state mv
2016-04-12 20:44:12 +02:00
bar = value
foo = value
`
const testStateMvOutput = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command/state mv
2016-04-12 20:44:12 +02:00
bar = value
foo = value
test_instance.baz:
ID = foo
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command/state mv
2016-04-12 20:44:12 +02:00
bar = value
foo = value
`
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
const testStateMvCount_stateOut = `
test_instance.bar.0:
ID = foo
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
bar = value
foo = value
test_instance.bar.1:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
bar = value
foo = value
`
const testStateMvCount_stateOutSrc = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
bar = value
foo = value
`
const testStateMvCount_stateOutOriginal = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
bar = value
foo = value
test_instance.foo.0:
ID = foo
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
bar = value
foo = value
test_instance.foo.1:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving resource with count [GH-7797]
2016-08-19 18:05:20 +02:00
bar = value
foo = value
`
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
const testStateMvLargeCount_stateOut = `
test_instance.bar.0:
ID = foo0
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.1:
ID = foo1
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.2:
ID = foo2
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.3:
ID = foo3
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.4:
ID = foo4
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.5:
ID = foo5
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.6:
ID = foo6
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.7:
ID = foo7
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.8:
ID = foo8
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.9:
ID = foo9
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.bar.10:
ID = foo10
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
`
const testStateMvLargeCount_stateOutSrc = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
`
const testStateMvLargeCount_stateOutOriginal = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.0:
ID = foo0
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.1:
ID = foo1
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.2:
ID = foo2
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.3:
ID = foo3
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.4:
ID = foo4
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.5:
ID = foo5
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.6:
ID = foo6
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.7:
ID = foo7
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.8:
ID = foo8
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.9:
ID = foo9
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
test_instance.foo.10:
ID = foo10
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
fix sorting of module resources during state mv Module resource were being sorted lexically by name by the state filter. If there are 10 or more resources, the order won't match the index order, and resources will have different indexes in their new location. Sort the FilterResults by index numerically when the names match. Clean up the module String output for visual inspection by sorting Resource name parts numerically when they are an integer value.
2017-02-24 00:27:16 +01:00
bar = value
foo = value
`
terraform: state mv tests
2016-08-18 21:05:42 +02:00
const testStateMvNestedModule_stateOut = `
terraform: fix some test failures on state add with multiple modules
2016-08-18 23:39:07 +02:00
<no state>
terraform: state mv tests
2016-08-18 21:05:42 +02:00
module.bar.child1:
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
terraform: state mv tests
2016-08-18 21:05:42 +02:00
bar = value
foo = value
module.bar.child2:
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
terraform: state mv tests
2016-08-18 21:05:42 +02:00
bar = value
foo = value
`
allow moving resource to new modules not in state Create the missing modules in the state when moving resources to a module that doesn't yet exist. This allows for refactoring of configuration into new modules, without having to create dummy resources in the module before the "state mv" operations.
2019-08-02 00:54:09 +02:00
const testStateMvNewModule_stateOut = `
<no state>
module.bar:
test_instance.bar:
ID = bar
provider = provider.test
bar = value
foo = value
`
const testStateMvModuleNewModule_stateOut = `
<no state>
module.foo:
test_instance.bar:
ID = bar
provider = provider.test
bar = value
foo = value
`
const testStateMvNewModule_stateOutOriginal = `
test_instance.bar:
ID = bar
provider = provider.test
bar = value
foo = value
`
terraform: state mv tests
2016-08-18 21:05:42 +02:00
const testStateMvNestedModule_stateOutSrc = `
<no state>
`
const testStateMvNestedModule_stateOutOriginal = `
<no state>
module.foo.child1:
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
terraform: state mv tests
2016-08-18 21:05:42 +02:00
bar = value
foo = value
module.foo.child2:
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
terraform: state mv tests
2016-08-18 21:05:42 +02:00
bar = value
foo = value
`
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
const testStateMvOutput_stateOut = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
bar = value
foo = value
`
const testStateMvOutput_stateOutSrc = `
<no state>
`
const testStateMvOutput_stateOutOriginal = `
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command/state mv: handle -state-out to a different path
2016-04-12 23:17:59 +02:00
bar = value
foo = value
`
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
const testStateMvExisting_stateSrc = `
<no state>
`
const testStateMvExisting_stateDst = `
test_instance.bar:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
bar = value
foo = value
test_instance.qux:
ID = bar
command/state: update and fix the state mv command
2018-10-25 15:41:00 +02:00
provider = provider.test
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
`
const testStateMvExisting_stateSrcOriginal = `
test_instance.foo:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
bar = value
foo = value
`
const testStateMvExisting_stateDstOriginal = `
test_instance.qux:
ID = bar
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
command: test for moving into another state file
2016-04-13 00:02:18 +02:00
`
add tests for state commands through a backend
2017-07-27 21:31:13 +02:00
const testStateMvOriginal_backend = `
test_instance.baz:
ID = foo
command: Stub the "terraform state mv" tests to remind to fix This command isn't yet updated for the new state types, but since we were not returning a non-successful error status here the tests were just failing in a weird way instead. Now we'll fail with a message that makes it clear there is still work to do in the real implementation here.
2018-10-13 18:41:44 +02:00
provider = provider.test
add tests for state commands through a backend
2017-07-27 21:31:13 +02:00
bar = value
foo = value
`