Worktype statusses unmanageable through Terraform

Platform API
1

Continuation from Impossible to keep track of worktype status changes with Terraform - #3 by rvgate

I got to test the new functionality to manage the statuses via Terraform using an independent resource.
It looks promising, but noticed a few issues that make it still unworkable, allow me to elaborate:

Categories are incorrect
The validation on the category only allows the values Open, Waiting, Closed and Unknown.
These categories are either wrong or incomplete, as InProgress is not allowed and impossible to define any status in this category...
Unknown does not show up anywhere either.

Default statuses are unmanageable (and blocking even)
By default, when creating a Worktype, it creates the statuses Open en Closed. There is no way to remove these using Terraform as the ID's are unknown to the tfstate.
Also, because these 2 statuses now exist, it is impossible to define the Open/Closed state in terraform, as they will return an error when creating them (status of the same name already exists)
So, I'm not able to remove them, not able to define them or edit them using Terraform, it requires an manual action in the UI to unblock.

Circular dependencies
When you define a status A, that allows an transition to status B and you define a status B that allows to transition to A, it is impossible to define this in Terraform due to a circular dependency.
Even though it is absolutely fine to do define this in the UI...

worktype_status
worktype_status1920×1080 141 KB

And the terraform file that i used:

resource "genesyscloud_task_management_worktype" "worktype" {
  # Details
  name               = var.name
  division_id        = var.division_id
  default_workbin_id = var.default_workbin_id
  schema_id          = var.schema_id
  description        = var.description

  # Properties
  default_duration_seconds     = 86400
  default_expiration_seconds   = 86400 * 90
  default_due_duration_seconds = 86400 * 15
  default_ttl_seconds          = 86400 * 365

  # Routing
  default_priority = -1000
}

# FIXME: Open is already created by default, so unable to define or remove it (same applies to Closed)
resource "genesyscloud_task_management_worktype_status" "Open" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Open"
  name        = "Open"
}

resource "genesyscloud_task_management_worktype_status" "AAA" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Open"
  name        = "AAA"
  destination_status_ids = [
    genesyscloud_task_management_worktype_status.BBB.id, # FIXME: Circular dependency with BBB
  ]
  default = true
}

resource "genesyscloud_task_management_worktype_status" "BBB" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Waiting"
  name        = "BBB"
  destination_status_ids = [
    genesyscloud_task_management_worktype_status.AAA.id, # FIXME: Circular dependency with AAA
  ]
}

resource "genesyscloud_task_management_worktype_status" "CCC" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Closed"
  name        = "CCC"
}

resource "genesyscloud_task_management_worktype_status" "DDD" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Unknown" # FIXME: Invalid category, does not show up anywhere in UI
  name        = "DDD"
}

# FIXME: Impossible to create a status in the InProgress category
resource "genesyscloud_task_management_worktype_status" "EEE" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "InProgress"
  name        = "EEE"
}
2

hi @rvgate will create a ticket to address these problems. Thanks for the detailed post with resource samples.

3

Regarding the InProgress status category, that seems to be fixed in version 1.55.0
The new allowed values are Open, Waiting, InProgress, Closed and Unknown.

Everything else mentioned is still a problem

4

Any update on this?

5

Almost 2 months in.... what is the status on this @Hemanth ?

6

Hi @rvgate

Apologies for responding late here.

Just want to decouple all the issues mentioned in the thread and give my two cents.

  • InProgress is not allowed --> This is resolved and it can be added a valid status

  • Tackle Circular dependencies.
    Essentially this is a terraform limitation where we cannot create two dependent resources at the same time. But we can update these once created. destination_status_ids is an optional attribute. Believe this need to be done in a two step process.

    1st step : create the resources without destination_status_ids

resource "genesyscloud_task_management_worktype_status" "AAA" {
worktype_id = genesyscloud_task_management_worktype.worktype.id
category    = "Open"
name        = "AAA"
default = true
}

resource "genesyscloud_task_management_worktype_status" "BBB" {
worktype_id = genesyscloud_task_management_worktype.worktype.id
category    = "Waiting"
name        = "BBB"
}

2nd step : Update the existing resources again with destination_status_ids

resource "genesyscloud_task_management_worktype_status" "AAA" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Open"
  name        = "AAA"
  destination_status_ids = [
    genesyscloud_task_management_worktype_status.BBB.id,
  ]
  default = true
}

resource "genesyscloud_task_management_worktype_status" "BBB" {
  worktype_id = genesyscloud_task_management_worktype.worktype.id
  category    = "Waiting"
  name        = "BBB"
  destination_status_ids = [
    genesyscloud_task_management_worktype_status.AAA.id, 
  ]
}

  • Unknown Status : We are in touch with the API team , why an unknown status is not being shown in the UI. Will get back to you as soon as I get info on it.

  • Open/Closed statuses auto creation: Its default API behaviour , where worktype statuses Open and Closed are created when a worktype is created. (Will get more info on the reasoning from API team)

    One solution for this is to incorporate the tfstate .
    Export all the resources back in a different directory with include_state_file = true. This way you can export the
    resources created and tfstate can be managed from this point. Sample export definition provided below.

resource "genesyscloud_tf_export" "feature" {
  directory = "./genesyscloud-worktypes”
  include_filter_resources = ["genesyscloud_task_management_worktype_status::.*","genesyscloud_task_management_worktype::.*"]
  enable_dependency_resolution = true
include_state_file = true
export_as_hcl = true
log_permission_errors = true
}

Hope this helps. Please let me know . Happy to assist.

Regards
Hemanth

7

What you mentioned are workarounds that become really cumbersome with larger terraform repositories, we manage about 700+ resources (acceptance only) and having these run multiple times (and tinker with statefile / exports) to get in the required state is not how terraform should work. Also making automated deployments impossible because it requires so much manual actions.

Possible solution for the 2 remaining problems could be the following;

New/Closes automatically created
This can be solved if the API has an option to skip the auto-creation and is on by default in the terraform module.

Circular dependencies
This can be solved by not declaring these destinations within the status resource, but have seperate resources to link them together.

Would these options be viable to implement? Anything is better than these workarounds...

8

Hey Rene,

Thanks for the thoughts. I need to chat with my team and the API team to see what are options are.

Thanks,
John Carnell
Director, Developer Engagement