Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename "state environments" to "workspaces" #14952

Merged
merged 10 commits into from
Jun 9, 2017
Merged

Conversation

apparentlymart
Copy link
Contributor

NOT TO BE MERGED UNTIL master IS TRACKING TOWARDS 0.10


After the "environments" feature was added in 0.9, we got lots of feedback that this terminology creates confusion due to it overlapping with several other non-equivalent concepts related to Terraform:

  • OS environment variables, like TF_LOG.
  • The word "environment" as used in the usage information for terraform init.
  • The idea of "environment" in Terraform Enterprise.

Furthermore, the word "environment" is often used in slightly- or wholly-inconsistent ways within organizations that use Terraform, creating further confusion as they try to map the feature onto their existing workflows.

In response, we've decided to rename this concept "workspace". This is honestly not that great a word either, but it has no existing conflicts within Terraform's concepts and we expect it will not be used in overlapping, conflicting ways within the vernacular of most organizations.

This PR deprecates many existing places that "env" or "environment" appear in the UX, replacing it with "workspace". The goal here is to support the old commands, variables and attributes from 0.10.0 until at least until 0.11.0, giving people time to switch over. (we will re-evaluate as we get closer to 0.11.0 whether it's feeling reasonable to remove support in that version.)

It leaves some aspects of the code with the old names, under the assumption that we can change these at our leisure without affecting backward compatibility. However, some obvious top-level names are changed, with the goal of reducing confusion for those who need to keep maintaining the code in the mean time.

This change includes @glasser's work from #14602, since this was the easiest way to also update that to use the environment variable TF_WORKSPACE without creating merge conflicts.

Copy link
Member

@jbardin jbardin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

backend.Operation still has a field named Environment too, as well as some environment related comments.

Otherwise, nice PR for such an extensive renaming!

DefaultEnvDir = "terraform.tfstate.d"
DefaultEnvFile = "environment"
DefaultWorkspaceDir = "terraform.tfstate.d"
DefaultWorkspaceFile = "environment"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is an internal detail, but should we migrate this file name too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was nervous about touching this right now because it would probably require some careful touches to make sure we don't inadvertently revert people back to default when they upgrade. I agree that we'd ideally change it, but my threshold for this initial change was either "easy and low-risk" or "in the UI", and this didn't pass either of those.

Of course, if you disagree with that as the goal then we can talk about that. 😀

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can agree with that ;) Just making sure it wasn't overlooked.

StateBackupPath string
StateEnvDir string
// StateWorkspaceDir is the path to the folder containing environments.
// This defaults to DefaultEnvDir if not set.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still a couple of env references in the comments here

@@ -385,28 +401,9 @@ func (b *Local) createState(name string) error {

// stateEnvDir returns the directory where state environments are stored.
func (b *Local) stateEnvDir() string {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

another env name and comment

@apparentlymart
Copy link
Contributor Author

I updated the extra things you pointed out, @jbardin. I think we'll need to accept some things being missed in this first pass, since it's primarily intended as a UI change, but I'm happy you caught a few more easy cases!

@cemo
Copy link

cemo commented Jun 1, 2017

@apparentlymart any idea about when master will be tracking 0.10? :)

@apparentlymart
Copy link
Contributor Author

@cemo we don't have the release plan finalized yet, but my guess would be that we'd do at least one more 0.9 release beforehand, since we've got a reasonable backlog of things to release.

glasser and others added 7 commits June 9, 2017 15:01
This allows you to run multiple concurrent terraform operations against
different environments from the same source directory.

Fixes #14447.

Also removes some dead code which appears to do the same thing as the function I
modified.
Feedback after 0.9 was that the term "environment" was confusing due to
it colliding with several other concepts, such as OS environment
variables, a non-aligned Terraform Enterprise concept, and differing ideas
of "environment" within various organizations.

This new term "workspace" is intended to ease some of that confusion. This
term is not used anywhere else in Terraform today, and we expect it to not
be used in a manner that would be confusing within user organizations.

This begins a deprecation cycle for the "terraform env" family of commands,
instead moving to an equivalent set of "terraform workspace" commands.

There are some remaining references to the old "environment" concept in
the code, which will be cleaned up in a separate change. This change is
instead focused on text visible in the UI and wording within code comments
for the benefit of human maintainers of the code.
As part of switching our terminology, we begin a deprecation cycle for
"environment_dir" and advise users to switch to "workspace_dir" instead.
Previously we just silently ignored warnings from validating the backend
config, but now that we have a deprecated argument it's important to print
these out so users can respond to the deprecation warning.
As part of our terminology shift, the interpolation variable for the name
of the current workspace changes to terraform.workspace. The old name
continues to be supported for compatibility.

We can't generate a deprecation warning from here so for now we'll just
silently accept terraform.env as an alias, but not mention it at all in
the error message in the hope that its use phases out over time before we
actually remove it.
This replaces the previous documentation on "State Environments", as part
of our intentional terminology shift.
We are moving away from using the term "environment" to describe separate
named states for a single config, using "workspace" instead. The old
attribute name remains supported for backward compatibility, but is
marked as deprecated.
We're shifting terminology from "environment" to "workspace". This takes
care of some of the main internal API surface that was using the old
terminology, though is not intended to be entirely comprehensive and is
mainly just to minimize the amount of confusion for maintainers as we
continue moving towards eliminating the old terminology.
We are replacing this terminology. The old command continues to work for
compatibility, but is deprecated. The docs should reflect the
currently-recommended form.
This is part of an effort to switch this terminology across all of
Terraform.
@ghost
Copy link

ghost commented Apr 11, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Apr 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants