Documentation incorrect for the aws_workspace_directory

[ghost]

This issue was originally opened by @csol01 as hashicorp/terraform#25628. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Hi There,

Apologies if this isn't the place to raise documentation issues, please point me in the right direction if I need to re-raise this elsewhere.

I've just been deploying out the aws_workspace_directory resource to register with a pre-existing directory service whereby only 1 of the directory service subnets is within an AZ that supports Workspaces. This isn't an issue as you can specify the subnets to use within the resource itself, and they don't need to be the subnets in which the directory service exists i.e.

resource "aws_workspaces_directory" "ms_ds" { directory_id = "<directory_id>" subnet_ids = [ "<subnet_id#1>", "<subnet_id#2>" ] }
However the documentation for this resource states that the subnet_ids value should be:

"(Optional) The identifiers of the subnets where the directory resides."

which is incorrect as it can be any subnets you want providing the workspaces facility is supported in those zones.

Chris.

[Tensho]

RegisterWorkspaceDirectory API action states SubnetIds parameter is not required, which means "No preferences" mode I guess (AWS service picks up available subnets for you). IMHO, it's user responsibility to determine the right AZs set, which supports AWS WorkSpaces service. It's hard to maintain constantly expanding list of AZs at provider's side and much easier to return error from the upstream AWS API.

Please consult "Availability Zones for Amazon WorkSpaces" to get the list of AWS WorkSpaces available AZs or contact AWS Support.

[csol01]

Hey Tensho, Thanks for getting back to me, it wasn’t really about the subnet of choice i.e. providing a list of subnets where Workspaces are available, merely the documentation stating the workspaces should reside in the same subnets as the directory service (which won’t always be the case) In my case I’d created the directory service months earlier and then a new requirement came in for a Workspace. Unfortunately only one of the zones that hosted the directory service subnets had AWS Workspaces available to it. I therefore had to generate new subnets for the workspaces to be deployed into and specify the optional parameter in the TF code. This resulted in 2 subnets hosting my directory service and another 2 subnets hosting the workspaces, hence my comment about the documentation being misleading as you don’t have to deploy workspaces into the same subnets that host your directory service as stated in the docs. Hope this clears up the point I’m making? Chris. From: Andrew Babichev <[email protected]> Sent: 10 August 2020 09:42 To: terraform-providers/terraform-provider-aws <[email protected]> Cc: Chris Needle <[email protected]>; Mention <[email protected]> Subject: Re: [terraform-providers/terraform-provider-aws] Documentation incorrect for the aws_workspace_directory (#14276) RegisterWorkspaceDirectory<https://docs.aws.amazon.com/workspaces/latest/api/API_RegisterWorkspaceDirectory.html#WorkSpaces-RegisterWorkspaceDirectory-request-SubnetIds> API action states SubnetIds parameter is not required, which means "No preferences" mode I guess (AWS service picks up available subnets for you). IMHO, it's user responsibility to determine the right AZs set, which supports AWS WorkSpaces service. It's hard to maintain constantly expanding list of AZs at provider's side and much easier to return error from the upstream AWS API. Please consult "Availability Zones for Amazon WorkSpaces"<https://docs.aws.amazon.com/workspaces/latest/adminguide/azs-workspaces.html> to get the list of AWS WorkSpaces available AZs or contact AWS Support. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#14276 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AM6D7PJLAACNIRPOPAHT6NTR76XGTANCNFSM4PDWXMPA>. The information included in this email and any files transmitted with it may contain information that is confidential and it must not be used by, or its contents or attachments copied or disclosed to, persons other than the intended addressee. If you have received this email in error, please notify BJSS. In the absence of written agreement to the contrary BJSS' relevant standard terms of contract for any work to be undertaken will apply. Please carry out virus or such other checks as you consider appropriate in respect of this email. BJSS does not accept responsibility for any adverse effect upon your system or data in relation to this email or any files transmitted with it. BJSS Limited, a company registered in England and Wales (Company Number 2777575), VAT Registration Number 613295452, Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR

[Tensho]

@csol01 Ah, I see your point – workspaces subnets not necessarily should be the same as directory subnets. You are totally right, they could be different. The subnets, where the directory service resides in, should be declared in aws_directory_service_directory.vpc_settings.subnet_ids attribute and the subnets, where workspaces are created, should be declared in aws_workspaces_directory.subnet_ids attribute. Thank you for clarification 🙇 Would you like to make your first contribution to AWS Terraform provider? 🙂

[ghost]

This has been released in version 3.11.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!