Multiple New Business Mappings Assigned Same ID During Apply

[detosu]

Howdy @skyscrapr, We're looking to define three business mappings via TF. Often, but not always, the 'terraform apply' will assign the SAME ID to each of the three:

Terraform has been successfully initialized! cloudability_business_mapping.TestRVP: Creating... cloudability_business_mapping.TestDepartment: Creating... cloudability_business_mapping.TestProduct: Creating... cloudability_business_mapping.TestDepartment: Creation complete after 1s [id=6] cloudability_business_mapping.TestRVP: Creation complete after 1s [id=6] cloudability_business_mapping.TestProduct: Creation complete after 1s [id=6] Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

As you can see above, id=6 was assigned to all three mappings. The result, as confirmed in the UI and API, is that only the last one, named 'TestProduct' was actually created.

[skyscrapr]

Interesting. Thanks for raising. I'll take a look.

Is this new behaviour? Or has this been consistent?

[detosu]

I think it has been around for awhile. I inherited the codebase, but I'm fairly certain this is the first time we've tried to create more than one mapping in one TF run.

Thank you!

[skyscrapr]

Can you please share the terraform config that you are using?

You can remove anything that might be sensitive.

This will help me create a test that covers your use case.

[skyscrapr]

I have created a test to create multiple business mappings

I have reproduced the issue. This looks like an issue with the API endpoint and maybe a caching issue. Can you please raise a ticket with Cloudability and refer to this GitHub issue?

This should get some focus from the Cloudability support team and get is resolved faster.

[skyscrapr]

Just to add for clarity. I'm having issues hitting the business mappings endpoint. I think Cloudability has some issues here and maybe trying to resolve this issue right now.

Please check in with your support team.

[skyscrapr]

Doing some investigation. This looks like an eventual consistency issue. The endpoint does accept the creation of new business mappings but fast repeated calls to the endpoint can result in the same if being re-used.

This can be solved with a wait. But seems like a bug to me and should be raised with apptio.

[detosu]

That explains what I was seeing exactly. We did open a ticket with them. Will see what they say. Thank you so much!

[skyscrapr]

I had a play to confirm the eventual consistency issue. You can work around the issue by implementing depends_on and time_sleep between resource creation. Here is a sample that worked for me. You can share this with apptio to confirm the issue is in the endpoint.

`provider "time" { version = "~> 0.7" }

resource "cloudability_business_mapping" "test1" { name = "test__1" default_value = "Unknown1" kind = "BUSINESS_DIMENSION" statement { match_expression = "DIMENSION['vendor'] == 'vendor1_1'" value_expression = "'Vendor1_1'" } statement { match_expression = "DIMENSION['vendor'] == 'vendor1_2'" value_expression = "'Vendor1_2'" } }

resource "time_sleep" "wait_test1" { depends_on = [cloudability_business_mapping.test1] create_duration = "2s" }

resource "cloudability_business_mapping" "test2" { name = "test__2" default_value = "Unknown2" kind = "BUSINESS_DIMENSION" statement { match_expression = "DIMENSION['vendor'] == 'vendor2_1'" value_expression = "'Vendor2_1'" } statement { match_expression = "DIMENSION['vendor'] == 'vendor2_2'" value_expression = "'Vendor2_2'" } depends_on = [time_sleep.wait_test1] }

resource "time_sleep" "wait_test2" { depends_on = [cloudability_business_mapping.test2] create_duration = "2s" }

resource "cloudability_business_mapping" "test3" { name = "test__3" default_value = "Unknown3" kind = "BUSINESS_DIMENSION" statement { match_expression = "DIMENSION['vendor'] == 'vendor3_1'" value_expression = "'Vendor3_1'" } statement { match_expression = "DIMENSION['vendor'] == 'vendor3_2'" value_expression = "'Vendor3_2'" } depends_on = [time_sleep.wait_test2] }`