Terraform enterprise support for project scoped workspaces.

[mikhail-khodorovskiy]

Describe the outcome you'd like

While setting up AFT module, we would like to use a Terraform project admin level token, not org admin level token and only create workspaces in that project as new per-account customizations pipelines are created.

Is your feature request related to a problem you are currently experiencing? If so, please describe.

In case the project-level admin token is used right now, the creation of the workspaces is failing. But, if the workspaces are created out-of-band in the correct project, the reruns of code pipeline succeed as it finds the workspaces with the project level token without problems.

Additional context

In our organization, we leverage terraform to mange our TFE tenant, and specifically https://registry.terraform.io/providers/hashicorp/tfe/latest/docs/resources/workspace to create workspaces. When the workspaces need to be created dynamically and not using the terraform model, we isolate those use cases to specific projects and that's why we would need AFT module to support the workspace creation to be done with the project scoped API token in the specified project.

[wellsiau-aws]

@mikhail-khodorovskiy , thanks for opening the issue.

If I understand the problem correctly, the error is caused by how AFT workspace manager creates the Terraform workspace without specifying the project ID. As such the workspace always defaulted to the Default Project and it failed. Please note that I haven't test this behavior myself.

Relates to #447 and #342

[mikhail-khodorovskiy]

Yes, the error I get from the account customization code pipeline on the TFE api call is below:

Handling errors: [{'status': '422', 'title': 'unprocessable entity', 'detail': 'Project not found, or you are not authorized to use it.'}]
--
291 | Traceback (most recent call last):
292 | File "/codebuild/output/src*********/src/aws-aft-core-framework/sources/scripts/workspace_manager.py", line 274, in <module>
293 | setup_and_run_workspace(
294 | File "/codebuild/output/src*********/src/aws-aft-core-framework/sources/scripts/workspace_manager.py", line 18, in setup_and_run_workspace
295 | workspace_id = setup_workspace(
296 | ^^^^^^^^^^^^^^^^
297 | File "/codebuild/output/src*********/src/aws-aft-core-framework/sources/scripts/workspace_manager.py", line 28, in setup_workspace
298 | workspace_id = terraform.create_workspace(
299 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
300 | File "/codebuild/output/src*********/src/aws-aft-core-framework/sources/scripts/terraform_client.py", line 59, in create_workspace
301 | response = __post(endpoint, headers, payload)
302 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
303 | File "/codebuild/output/src*********/src/aws-aft-core-framework/sources/scripts/terraform_client.py", line 215, in __post
304 | __handle_errors(response)
305 | File "/codebuild/output/src*********/src/aws-aft-core-framework/sources/scripts/terraform_client.py", line 253, in __handle_errors
306 | raise ClientError(status=error["status"], message=error["title"])
307 | terraform_client.ClientError: unprocessable entity

After I create the project via TFC config terraform provider in another repository in the specific project with tags, the rerun of the pipeline succeeds.

[jpablos11]

@wellsiau-aws , I was about to open a Feature Request then realized this conversation comes close enough to what I would like to propose, I will just word it from another angle.

I think supporting a "terraform_project" or "terraform_project_id" input would be very beneficial to those using Terraform Cloud (on the same level as "terraform_distribution", "terraform_org_name" and "terraform_token"), let me elaborate with an example:

• An Org required us to put all AFT workspaces in a particular Terraform Cloud project, let's say "aft-control-tower", but there is no option to customize this so all workspaces AFT creates currently land on Default Project by default.
• At first we did not have permissions for Default Project so the pipeline was failing, this can be solved by adjusting TC permissions, but an angle to consider (in restricted envs, permissions might allow access to certain projects only).
• To fulfill this requirement, the only option is to let AFT create all workspaces in Default Project, and then manually change them to their final destination one-by-one, or rename the Default Project (but it might not be possible for everyone), which is less than optimal (specially if we are talking about a big number of accounts: manual edits = two workspaces x account).
• My proposal is to add a "terraform_project" or "terraform_project_id" input to the module, so new workspaces land from creation in the right place. Adding "project_name" would be better if it is possible (and create the project if it doesn't exist), but either would do.
• Looking at the Python code in workspace_manager.py, a "project_name" or "project_id" parameter could be added to the "create_workspace" function, and its value taken or produced from the new input when available):
  

Hope this makes sense. Cheers!

[wellsiau-aws]

Make sense @jpablos11 , just had very similar conversation with another customer earlier last week.

The consensus that I got is set project_name / project_id at the root level (AFT module).

note: not ideal, but you could potentially work-around this by using the post-API helper if this really bugging you.

[jpablos11]

@wellsiau-aws , that sounds great and thank you for the quick response!

Thank you also for the post-API helper idea, that might do for the time being.