This project is mirrored from https://:*****@github.com/hashicorp/terraform.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
  1. 26 Jan, 2021 1 commit
  2. 12 Oct, 2020 1 commit
  3. 17 Sep, 2020 1 commit
  4. 11 Aug, 2020 1 commit
    • Kristin Laemmert's avatar
      * backend/local: push responsibility for unlocking state into individual operations · 86e9ba3d
      Kristin Laemmert authored
      * unlock the state if Context() has an error, exactly as backend/remote does today
      * terraform console and terraform import will exit before unlocking state in case of error in Context()
      * responsibility for unlocking state in the local backend is pushed down the stack, out of backend.go and into each individual state operation
      * add tests confirming that state is not locked after apply and plan
      
      * backend/local: add checks that the state is unlocked after operations
      
      This adds tests to plan, apply and refresh which validate that the state
      is unlocked after all operations, regardless of exit status. I've also
      added specific tests that force Context() to fail during each operation
      to verify that locking behavior specifically.
      86e9ba3d
  5. 29 May, 2020 1 commit
    • Martin Atkins's avatar
      backend/local: treat output changes as side-effects to be applied · 31a4b44d
      Martin Atkins authored
      This is a baby-step towards an intended future where all Terraform actions
      which have side-effects in either remote objects or the Terraform state
      can go through the plan+apply workflow.
      
      This initial change is focused only on allowing plan+apply for changes to
      root module output values, so that these can be written into a new state
      snapshot (for consumption by terraform_remote_state elsewhere) without
      having to go outside of the primary workflow by running
      "terraform refresh".
      
      This is also better than "terraform refresh" because it gives an
      opportunity to review the proposed changes before applying them, as we're
      accustomed to with resource changes.
      
      The downside here is that Terraform Core was not designed to produce
      accurate changesets for root module outputs. Although we added a place for
      it in the plan model in Terraform 0.12, Terraform Core currently produces
      inaccurate changesets there which don't properly track the prior values.
      
      We're planning to rework Terraform Core's evaluation approach in a
      forthcoming release so it would itself be able to distinguish between the
      prior state and the planned new state to produce an accurate changeset,
      but this commit introduces a temporary stop-gap solution of implementing
      the logic up in the local backend code, where we can freeze a snapshot of
      the prior state before we take any other actions and then use that to
      produce an accurate output changeset to decide whether the plan has
      externally-visible side-effects and render any changes to output values.
      
      This temporary approach should be replaced by a more appropriately-placed
      solution in Terraform Core in a release, which should then allow further
      behaviors in similar vein, such as user-visible drift detection for
      resource instances.
      31a4b44d
  6. 21 Nov, 2019 1 commit
  7. 17 Sep, 2019 1 commit
    • Martin Atkins's avatar
      core: Warn when creating and applying with -target · 7e29b9b5
      Martin Atkins authored
      The documentation for the -target option warns that it's intended for
      exceptional circumstances only and not for routine use, but that's not a
      very prominent location for that warning and so some users miss it.
      
      Here we make the warning more prominent by including it directly in the
      Terraform output when -target is in use. We first warn during planning
      that the plan might be incomplete, and then warn again after apply
      concludes and direct the user to run "terraform plan" to make sure that
      there are no further changes outstanding. The latter message is intended
      to reinforce that -target should only be a one-off operation and that you
      should always run without it soon after to ensure that the workspace is
      left in a consistent, converged state.
      7e29b9b5
  8. 27 Mar, 2019 1 commit
    • Sander van Harmelen's avatar
      backend/local: preserve serial and lineage on failure · 57f6e018
      Sander van Harmelen authored
      When failing to write the state, the local backend writes the state to a local file called `errrored.tfstate`. Previously it would do so by creating a new state file which would use a new serial and lineage. By exorting the existing state file and directly assigning the new state, the serial and lineage are preserved.
      57f6e018
  9. 08 Mar, 2019 1 commit
  10. 06 Mar, 2019 1 commit
  11. 06 Nov, 2018 1 commit
  12. 17 Oct, 2018 7 commits
    • Martin Atkins's avatar
      backend/local: Increase log verbosity for backend context construction · c5940f24
      Martin Atkins authored
      There are several steps here and a number of them can include reaching out
      to remote servers or executing local processes, so it's helpful to have
      some trace logs to better narrow down causes of errors and hangs during
      this step.
      c5940f24
    • Kristin Laemmert's avatar
    • Kristin Laemmert's avatar
      2808df48
    • Martin Atkins's avatar
      command: initial structural diff rendering · 239a54ad
      Martin Atkins authored
      This is a light adaptation of our earlier prototype of structural diff
      rendering, as a starting point for what we'll actually ship. This is not
      consistent with the latest mocks, so will need some additional work before
      it is ready, but integrating this allows us to at least see the plan
      contents while fixing up remaining issues elsewhere.
      239a54ad
    • Martin Atkins's avatar
      terraform: Ugly huge change to weave in new State and Plan types · a3403f27
      Martin Atkins authored
      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 5861dbf3 before, I apologize
      in advance to the person who inevitably just found this huge commit while
      spelunking through the commit history.
      a3403f27
    • Martin Atkins's avatar
      terraform: ugly huge change to weave in new HCL2-oriented types · c937c06a
      Martin Atkins authored
      Due to how deeply the configuration types go into Terraform Core, there
      isn't a great way to switch out to HCL2 gradually. As a consequence, this
      huge commit gets us from the old state to a _compilable_ new state, but
      does not yet attempt to fix any tests and has a number of known missing
      parts and bugs. We will continue to iterate on this in forthcoming
      commits, heading back towards passing tests and making Terraform
      fully-functional again.
      
      The three main goals here are:
      - Use the configuration models from the "configs" package instead of the
        older models in the "config" package, which is now deprecated and
        preserved only to help us write our migration tool.
      - Do expression inspection and evaluation using the functionality of the
        new "lang" package, instead of the Interpolator type and related
        functionality in the main "terraform" package.
      - Represent addresses of various objects using types in the addrs package,
        rather than hand-...
      c937c06a
    • Martin Atkins's avatar
      backend: Update interface and implementations for new config loader · 5782357c
      Martin Atkins authored
      The new config loader requires some steps to happen in a different
      order, particularly in regard to knowing the schema in order to
      decode the configuration.
      
      Here we lean directly on the configschema package, rather than
      on helper/schema.Backend as before, because it's generally
      sufficient for our needs here and this prepares us for the
      helper/schema package later moving out into its own repository
      to seed a "plugin SDK".
      5782357c
  13. 22 Sep, 2018 1 commit
  14. 19 Jun, 2018 1 commit
  15. 23 Feb, 2018 5 commits
    • James Bardin's avatar
      create clistate.Locker interface · e9a76808
      James Bardin authored
      Simplify the use of clistate.Lock by creating a clistate.Locker
      instance, which stores the context of locking a state, to allow unlock
      to be called without knowledge of how the state was locked.
      
      This alows the backend code to bring the needed UI methods to the point
      where the state is locked, and still unlock the state from an outer
      scope.
      
      Provide a NoopLocker as well, so that callers can always call Unlock
      without verifying the status of the lock.
      
      Add the StateLocker field to the backend.Operation, so that the state
      lock can be carried between the different function scopes of the backend
      code. This will allow the backend context to lock the state before it's
      read, while allowing the different operations to unlock the state when
      they complete.
      e9a76808
    • James Bardin's avatar
      Revert "create clistate.Locker interface" · 12bda535
      James Bardin authored
      This reverts commit e88bd74b.
      12bda535
    • James Bardin's avatar
      Revert "use the new clistate.Locker in the local backend" · 1d9adc3b
      James Bardin authored
      This reverts commit 0b804a96.
      1d9adc3b
    • James Bardin's avatar
      use the new clistate.Locker in the local backend · 0b804a96
      James Bardin authored
      Use the new StateLocker field to provide a wrapper for locking the state
      during terraform.Context creation. We can then remove all the state
      locking code from individual operations, and unlock them in one place
      inside the main Operation method.
      0b804a96
    • James Bardin's avatar
      create clistate.Locker interface · e88bd74b
      James Bardin authored
      Simplify the use of clistate.Lock by creating a clistate.Locker
      instance, which stores the context of locking a state, to allow unlock
      to be called without knowledge of how the state was locked.
      
      This alows the backend code to bring the needed UI methods to the point
      where the state is locked, and still unlock the state from an outer
      scope.
      e88bd74b
  16. 12 Feb, 2018 2 commits
    • James Bardin's avatar
      coalesce the backened interrupt code · ef8ed1e2
      James Bardin authored
      Moves the nested select statements for backend operations into a single
      function. The only difference in this part was that apply called
      PersistState, which should be harmless regardless of the type of
      operation being run.
      ef8ed1e2
    • James Bardin's avatar
      always wait for a RunningOperation to return · 7cba6832
      James Bardin authored
      If the user wishes to interrupt the running operation, only the first
      interrupt was communicated to the operation by canceling the provided
      context. A second interrupt would start the shutdown process, but not
      communicate this to the running operation. This order of event could
      cause partial writes of state.
      
      What would happen is that once the command returns, the plugin system
      would stop the provider processes. Once the provider processes dies, all
      pending Eval operations would return return with an error, and quickly
      cause the operation to complete. Since the backend code didn't know that
      the process was shutting down imminently, it would continue by
      attempting to write out the last known state. Under the right
      conditions, the process would exit part way through the writing of the
      state file.
      
      Add Stop and Cancel CancelFuncs to the RunningOperation, to allow it to
      easily differentiate between the two signals. The backend will then be
      able to detect a shutdown and abort more gracefully.
      
      In order to ensure that the backend is not in the process of writing the
      state out, the command will always attempt to wait for the process to
      complete after cancellation.
      7cba6832
  17. 01 Feb, 2018 1 commit
    • Laura Martin's avatar
      Change -force to -auto-approve when destroying · 6e1e614a
      Laura Martin authored
      Since an early version of Terraform, the `destroy` command has always
      had the `-force` flag to allow an auto approval of the interactive
      prompt. 0.11 introduced `-auto-approve` as default to `false` when using
      the `apply` command.
      
      The `-auto-approve` flag was introduced to reduce ambiguity of it's
      function, but the `-force` flag was never updated for a destroy.
      
      People often use wrappers when automating commands in Terraform, and the
      inconsistency between `apply` and `destroy` means that additional logic
      must be added to the wrappers to do similar functions. Both commands are
      more or less able to run with similar syntax, and also heavily share
      their code.
      
      This commit updates the command in `destroy` to use the `-auto-approve` flag
      making working with the Terraform CLI a more consistent experience.
      
      We leave in `-force` in `destroy` for the time-being and flag it as
      deprecated to ensure a safe switchover period.
      6e1e614a
  18. 05 Dec, 2017 1 commit
  19. 02 Sep, 2017 2 commits
    • Martin Atkins's avatar
      command: various adjustments to the diff presentation · 83414beb
      Martin Atkins authored
      The previous diff presentation was rather "wordy", and not very friendly
      to those who can't see color either because they have color-blindness or
      because they don't have a color-supporting terminal.
      
      This new presentation uses the actual symbols used in the plan output
      and tries to be more concise. It also uses some framing characters to
      try to separate the different stages of "terraform plan" to make it
      easier to visually navigate.
      
      The apply command also adopts this new plan presentation, in preparation
      for "terraform apply" (with interactive plan confirmation) becoming the
      primary, safe workflow in the next major release.
      
      Finally, we standardize on the terminology "perform" and "actions" rather
      than "execute" and "changes" to reflect the fact that reading is now an
      action and that isn't actually a _change_.
      83414beb
    • Martin Atkins's avatar
      command/format: improve consistency of plan results · 3ea15929
      Martin Atkins authored
      Previously the rendered plan output was constructed directly from the
      core plan and then annotated with counts derived from the count hook.
      At various places we applied little adjustments to deal with the fact that
      the user-facing diff model is not identical to the internal diff model,
      including the special handling of data source reads and destroys. Since
      this logic was just muddled into the rendering code, it behaved
      inconsistently with the tally of adds, updates and deletes.
      
      This change reworks the plan formatter so that it happens in two stages:
      - First, we produce a specialized Plan object that is tailored for use
        in the UI. This applies all the relevant logic to transform the
        physical model into the user model.
      - Second, we do a straightforward visual rendering of the display-oriented
        plan object.
      
      For the moment this is slightly overkill since there's only one rendering
      path, but it does give us the benefit of letting the counts be derived
      from the same data as the full detailed diff, ensuring that they'll stay
      consistent.
      
      Later we may choose to have other UIs for plans, such as a
      machine-readable output intended to drive a web UI. In that case, we'd
      want the web UI to consume a serialization of the _display-oriented_ plan
      so that it doesn't need to re-implement all of these UI special cases.
      
      This introduces to core a new diff action type for "refresh". Currently
      this is used _only_ in the UI layer, to represent data source reads.
      Later it would be good to use this type for the core diff as well, to
      improve consistency, but that is left for another day to keep this change
      focused on the UI.
      3ea15929
  20. 29 Jun, 2017 1 commit
  21. 27 Jun, 2017 3 commits
  22. 25 May, 2017 1 commit
    • James Bardin's avatar
      call PersistState immediately when cancelling · 9e4c0ff2
      James Bardin authored
      When the backend operation is cancelled, immediately call PersistState.
      The is a high likelihood that the user is going to terminate the process
      early if the provider doesn't return in a timely manner, so persist as
      much state as possible.
      9e4c0ff2
  23. 23 May, 2017 1 commit
    • Martin Atkins's avatar
      backend/local: create local state file if backend write fails · 9cda3720
      Martin Atkins authored
      In the old remote state system we had the idea of a local backup, which
      is actually still present for the legacy backends but no longer applies
      for the new-style backends like the s3 backend.
      
      It's problematic when an apply runs for long enough that someone's
      time-limited AWS STS credentials expire and then Terraform fails and can't
      persist state to S3.
      
      To reduce the risk of lost state, here we add some extra fallback code
      for the local apply operation in particular. If either state writing
      or state persisting fail then we attempt to write the state to a special
      backup file errored.tfstate, and produce an error message that guides the
      user on how to retry uploading this state.
      
      In the unlikely event that we can't write to local disk either (e.g.
      permissions problems) we take a last-ditch attempt to dump the JSON onto
      stdout and advise the user to manually copy it into a file for import.
      If even that doesn't work for some reason, we assume a critical Terraform
      bug (JSON-serialization problem with states?) and bail out with an
      apologetic error message.
      
      This is implemented for the apply command in particular because this is
      the one command where new objects are created in real APIs that we don't
      want to lose track of. For other operations it's less bad to just generate
      a simple error message and have the user retry.
      
      This fixes #14298.
      9cda3720
  24. 25 Apr, 2017 1 commit
  25. 14 Apr, 2017 1 commit
    • James Bardin's avatar
      context Refresh and Apply sometimes return nil · 928e6067
      James Bardin authored
      The documentation for Refresh indicates that it will always return a
      valid state, but that wasn't true in the case of a graph builder error.
      While this same concept wasn't documented for Apply, it was still
      assumed in the terraform apply code.
      
      Since the helper testing framework relies on the absence of a state to
      determine if it can call Destroy, the Context can't can't start
      returning a state in all cases. Document this, and use the State method
      to fetch the correct state value after Apply.
      
      Add a nil check to the WriteState function, so that writing a nil state
      is a noop.
      
      Make sure to init before sorting the state, to make sure we're not
      attempting to sort nil values. This isn't technically needed with the
      current code, but it's just safer in general.
      928e6067
  26. 01 Apr, 2017 1 commit
    • James Bardin's avatar
      provide contexts to clistate.Lock calls · 305ef43a
      James Bardin authored
      Add fields required to create an appropriate context for all calls to
      clistate.Lock.
      
      Add missing checks for Meta.stateLock, where we would attempt to lock,
      even if locking should be skipped.
      305ef43a