Decouple tenant and project environments

[hans-m-song]

trafficstars

Is your feature request related to a problem? Please describe.

In a Terraform workspace in which there can be many projects associated to a single tenant, it is frustrating to have to manage the connections in the tenant resource and is difficult to scale.

I would like to be able to manage tenant connections separately to the tenant itself.

Describe the solution you'd like

I noticed the connections are an attribute of the tenant in the API which is somewhat problematic. I also observed when creating the connection from settings of a project, it appears to update the tenant resource.

I propose the addition of a octopusdeploy_tenant_connection resource which manages the ProjectEnvironments attribute of a tenant.

I expect the Terraform config to look something along the lines of

# infrastructure.tf
resource "octopusdeploy_tenant" "apse2" {
	...
	lifecycles {
		ignore = [project_environment]
	}
}

# petcorp.tf
resource "octopusdeploy_project" "pet_clinic" { ... }

resource "octopusdeploy_tenant_connection" "petclinic_apse2" {
	project_id      = octopusdeploy_project.petclinic.id
	tenant_id       = octopusdeploy_tenant.apse2.id
	environment_ids = [octopusdeploy_environment.dev.id]
}

resource "octopusdeploy_project" "quadruped_wellness_centre" { ... }

resource "octopusdeploy_tenant_connection" "quadruped_wellness_centre_apse2" {
	project_id      = octopusdeploy_project.quadruped_wellness_centre.id
	tenant_id       = octopusdeploy_tenant.apse2.id
	environment_ids = [octopusdeploy_environment.dev.id, octopusdeploy_environment.prod.id]
}

Describe alternatives you've considered

I have made a functional POC here.

Additional context

N/A

---

I would be interested in raising a PR but I have very limited experience with developing Terraform providers

[hans-m-song]

FYI - @mcasperson

[zentron]

Hi @hans-m-song could you elaborate on the way that the current model is problematic.

At the moment the Terraform provider data model pretty closely maps to the API data model which has made the development and maintenance of the provider simpler, although potentially at the expense of forcing the user to hold the resources in a way that might not be TF native. The more feedback we can get on this the better.

While we don't have immediate capacity to implement this potentially breaking change, I would be happy to learn more about the problems the current implementation is causing so we can better gauge how to prioritize this request.

[hans-m-song]

Hi @zentron, thanks for having a look at this.

To preface this - the existence of this provider is highly appreciated. IAC is fairly important to my team as there just isn't enough fingers to do what we need to do with pure click-ops.

My team is currently paving the way to adopting Octopus Deploy into a decent number of pre-existing CI/CD pipelines which (apart from a few snowflakes) follow a few well-known patterns. Our instance is configured with a 1<>1 relationship between tenants and deployment targets (representing Kubernetes clusters, cloud regions, etc). With our current progress, our tenants have anywhere between 1-9 projects with more to come.

Our current approach is to create a Terraform module for each of these deployment processes and stamp out projects en-masse. The current model provides some friction as the connections are often forgotten. In an ideal world, I imagine we would encapsulate the project and tenant connection within the aforementioned module.

In regards to prioritisation, I would consider this a "really nice to have" but it ranks fairly low in amongst the issues we've encountered while using this provider.

this potentially breaking change

While I can't speak to whether or not it is an acceptable convention, the suggested lifecycle directive means the resource can be opt-in. The provider I published is also a functional proof of concept which works with the existing data model.

[hnrkndrssn]

Fixed in https://github.com/OctopusDeployLabs/terraform-provider-octopusdeploy/pull/676